On Mon 23-Jun-08 3:33pm -0600, Bram Moolenaar wrote:
I get the feeling we are splitting hairs here. Anyway, current Vim does
like the above. Except:
:echo PG(-0.00123)
-1.23e-3
I would prefer to see -0.00123, as Vim does now.
You can now control the number of zeros you get
Bill McCarthy wrote:
On Sun 22-Jun-08 2:49pm -0600, Tony Mechelynck wrote:
On 21/06/08 13:56, Bram Moolenaar wrote:
Ben Schmidt wrote:
- Furthermore, on investigation, it seems there is an interesting
definition of 'significant figures' in the library docs, and %.15g =
is
Bram Moolenaar wrote:
- Added a test. Please try this, I don't know if roundoff
errors might break it.
It's a trivial issue, but test65 (floating point) disagrees with Microsoft
Visual C
MSVC 6.0.
Line 11 of test65.in is:
:$put =printf('%e', 123.456)
Corresponding result expected in
[Actually the patch I attached goes over a couple of other patches I also
had applied; but it still applies to the current source and runtimes OK,
just with some offsets.]
Ben Schmidt wrote:
I'm not sure how to add the variables.
I am. :-)
I've patched 7.1.386 with the new floating point
Ben Schmidt wrote:
You are apparently looking at slightly outdated runtime files. I'll
push the current version now, so that they match with the latest
floating point patch.
Yep. They look better now. Two suggestions for improvement:
- An example of pow() with floats would be good.
Bram Moolenaar wrote:
OK, so Borland doesn't have round() and trunc(). I rather
not have a Vim version with only part of the floating point
support. The easy solution is to disable it for Borland in
src/feature.h:
#ifdef FEAT_NORMAL
# define FEAT_EVAL
# if
I don't see what you mean. If you want to convert a Number to a Float
you can add 0.0 to it.
I misinterpreted you in my previous reply. I just realised what you
meant. That makes sense.
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev
Please do read my earlier replies where I note this and other things in
more detail, and provide patches to achieve them (by the way, I'm happy
to fiddle with the patch if you want things done differently/removed if
it makes things easier for you). I just realised something else
though...
Ben -
- If the default display precision is to remain at six, documenting this
would be good, at the same time noting that printf() can be used to
display with greater precision.
Document this where?
Where the precision of floats is discussed makes most sense. I've sent a
- Furthermore, on investigation, it seems there is an interesting
definition of 'significant figures' in the library docs, and %.15g is
the correct value, not %.16g. It might be worth noting at the printf()
docs, or the Float docs where precision is mentioned, or both, that
On Sat 21-Jun-08 9:04am -0600, Bram Moolenaar wrote:
OK, just adding sin(), cos() and atan() sounds reasonable.
Sure, if you don't use trig, log or exp functions - that
sounds reasonable. Personally patching eval.c isn't all
that bad - only 40 of the first 326 patches changed eval.c
and I
On Sat 21-Jun-08 11:41pm -0600, John Beckett wrote:
My conclusion is that some variation of my earlier
suggested code should be included
in Vim so it does not rely on an external library for round/trunc.
This is much more reasonable than simply excluding some
users from the benefits of
Hi,
Patrick Texier wrote:
Le Fri, 20 Jun 2008 11:37:51 +0200, Bram Moolenaar a écrit dans le
message [EMAIL PROTECTED] :
I have made a few more improvements:
Thanks Bram.
Using Borland C++ 5.5 (HUGE with FLOAT), I had the following warnings :
.\eval.c:
Warning W8065 .\eval.c
.\eval.c:
Warning W8065 .\eval.c 14642: Call to function 'round' with no prototype
in function f_round
Warning W8065 .\eval.c 17027: Call to function 'trunc' with no prototype
in function f_trunc
As a workaround in eval.c you can simply replace
rettv-vval.v_float = round(f);
Patrick Texier wrote:
On Fri, 20 Jun 2008 14:29:07 +0200, Vladimir Marek wrote:
I don't have the previous post.
As a workaround in eval.c you can simply replace
rettv-vval.v_float = round(f);
with
rettv-vval.v_float = ceil(f + 0.5);
Yes.
I think it's:
if (f 0)
Patrick Texier wrote:
Le Fri, 20 Jun 2008 11:37:51 +0200, Bram Moolenaar a écrit dans le
message [EMAIL PROTECTED] :
I have made a few more improvements:
Thanks Bram.
Using Borland C++ 5.5 (HUGE with FLOAT), I had the following warnings :
.\eval.c:
Warning W8065 .\eval.c
On Fri, 20 Jun 2008 17:31:03 +0200, Bram Moolenaar wrote:
I think it's:
if (f 0)
return floor(f + 0.5)
else
return ceil(f - 0.5)
Otherwise -1.5 doesn't work like round() does. Glad we have a test to
verify this :-)
Yes, I had test my round() function with
With a small amount of testing, it's looking good, Bram. Tests says ALL
DONE which I presume means they all passed.
A few points:
- Wouldn't float2nr() be more consistent with the other Vim functions
than float2number()? O yes! So much so that it seems that's what you
implemented it as.
Bram Moolenaar wrote:
Patrick Texier wrote:
On Fri, 20 Jun 2008 14:29:07 +0200, Vladimir Marek wrote:
I don't have the previous post.
As a workaround in eval.c you can simply replace
rettv-vval.v_float = round(f);
with
rettv-vval.v_float = ceil(f + 0.5);
Yes.
I think it's:
On Fri 20-Jun-08 3:08pm -0600, Bram Moolenaar wrote:
Ben Schmidt wrote:
- No chance of getting sin(), cos(), atan() and log10()? I realised
after thinking a bit further and reading some other users' posts that
these actually would truly be useful. Surely they would only take a
few
You are apparently looking at slightly outdated runtime files. I'll
push the current version now, so that they match with the latest
floating point patch.
Yep. They look better now. Two suggestions for improvement:
- An example of pow() with floats would be good. E.g. pow(32,0.20)=2.0
Bill McCarthy wrote:
On Fri 20-Jun-08 3:08pm -0600, Bram Moolenaar wrote:
Ben Schmidt wrote:
- No chance of getting sin(), cos(), atan() and log10()? I realised
after thinking a bit further and reading some other users' posts that
these actually would truly be useful. Surely they would
- No chance of getting sin(), cos(), atan() and log10()? I realised
after thinking a bit further and reading some other users' posts that
these actually would truly be useful. Surely they would only take a
few minutes to implement, no time to maintain, and I would have a lot
of
John Beckett wrote:
Bram Moolenaar wrote:
g and G omit superfluos zeroes, as well as the decimal point:
double n = 12;
printf(%g\n, n); // prints 12
printf(%#g\n, n); // prints 12.
Vim is already using %g. For me the results are different.
In Vim, the code in
Here though, instead of Vince's patch one could send the text to a
browser, maybe a console-mode one such as Lynx displaying in Vim's (not
gvim's) own console, or else something like :exe '!seamonkey -url
file:///' . expand('%:p') or similar (for full generality one would
need to
Bram Moolenaar wrote:
g and G omit superfluos zeroes, as well as the decimal point:
double n = 12;
printf(%g\n, n); // prints 12
printf(%#g\n, n); // prints 12.
Vim is already using %g. For me the results are different.
In Vim, the code in vim_snprintf() (in message.c)
Ben Schmidt wrote:
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.
Not that I object to a built-in PRNG to vim; however, writing a plugin
to do
Mikołaj Machowski wrote:
Dnia 10-06-2008 o godz. 6:04 Gautam Iyer napisał(a):
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
On 10/06/08 15:09, Charles E Campbell Jr wrote:
[...]
Whereas, requiring a vim to include the interfaces to
python/ruby/pick-your-poison ... well, now you're talking real bloat (as
in increasing the vim executable size).
Regards,
Chip Campbell
Well, like you I think, I believe that
Tony Mechelynck wrote:
On 10/06/08 15:09, Charles E Campbell Jr wrote:
[...]
Whereas, requiring a vim to include the interfaces to
python/ruby/pick-your-poison ... well, now you're talking real bloat (as
in increasing the vim executable size).
Regards,
Chip Campbell
Well, like
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
On Tue, Jun 10, 2008 at 09:09:38AM -0400, Charles E Campbell Jr wrote:
Whereas, requiring a vim to include the interfaces to
python/ruby/pick-your-poison ... well, now you're talking real bloat
(as in increasing the vim executable size).
Not really! I never compile those in anyway :). Maybe I
On 10/06/08 21:02, Bram Moolenaar wrote:
Ben Schmidt wrote:
[...]
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.
I
On 10/06/08 21:37, Gautam Iyer wrote:
On Tue, Jun 10, 2008 at 09:09:38AM -0400, Charles E Campbell Jr wrote:
Whereas, requiring a vim to include the interfaces to
python/ruby/pick-your-poison ... well, now you're talking real bloat
(as in increasing the vim executable size).
Not really! I
Bram Moolenaar wrote:
I mean: Vim is using the library printf() to do the
conversion, but I don't see a way to tell printf() to omit
superfluous zeroes.
g and G omit superfluos zeroes, as well as the decimal point:
double n = 12;
printf(%g\n, n); // prints 12
printf(%#g\n, n); //
Bram Moolenaar wrote:
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
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
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
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
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.
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
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
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
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:
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
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
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
--
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])
Bill McCarthy wrote:
On Sun 8-Jun-08 11:19am -0600, Bram Moolenaar wrote:
Attached you will find the latest floating point patch. This goes on
top of the current Vim sources (7.1.311). If you included a previous
version of the floating point patch you need to remove that first.
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
Bram Moolenaar wrote:
[...]
I would still like feedback on the format of floating point numbers:
123.456
1.23e-3
I did a search for vim scripts that use concatenation operation between two
numbers without interleaving space. It appears that Google Code Search was
able to
OTOH, with there is no ambiguity because the various uses of are
strictly separated:
Actually, there still is ambiguity unless one requires a decimal point or
exponent. Without that restriction
123.456
could still mean 123 (or 123.0) concatenated with 456. But with the restriction
123
Charles E Campbell Jr wrote:
Ben Schmidt wrote:
Ben Schmidt wrote:
OTOH, with there is no ambiguity because the various uses of are
strictly separated:
Actually, there still is ambiguity unless one requires a decimal point or
exponent. Without that restriction
123.456
Ben Schmidt wrote:
Charles E Campbell Jr wrote:
Ben Schmidt wrote:
Ben Schmidt wrote:
OTOH, with there is no ambiguity because the various uses of are
strictly separated:
Actually, there still is ambiguity unless one requires a decimal point or
Bram Moolenaar wrote:
Second, the lhs and rhs of the '.' can each overflow an
integer, giving chaos.
:let a=str2float('0.3111222333')
:echo a
Result: -0.118374
How do you suggest to fix this?
I still think that using strtod() would be best, but curiosity got the better
of me
and I
Moolenaar
Subject: Re: Updated floating point patch
On Sat, Apr 12, 2008 at 4:58 PM, Bram Moolenaar [EMAIL PROTECTED] wrote:
Here is an update for the floating point patch. The 'g' argument for
printf() was implemented and a few bug fixes.
This is to be applied to the original source code, without
John Beckett wrote:
Bram Moolenaar wrote:
Here is an update for the floating point patch.
I've done a bit more testing with the latest floating point patch.
Vim's floating point doesn't need to cover all extremes, but the
following shows some bad results.
:help floating-point-format
Bram Moolenaar wrote:
Here is an update for the floating point patch. The 'g' argument for
printf() was implemented and a few bug fixes.
I have compiled with this updated floating point patch under win32. Here are
some
issues you might like to address.
os_win32.h now has '#define HAVE_POW
Mikolaj Machowski wrote:
Dnia Saturday 12 of April 2008, Bram Moolenaar napisa³:
Here is an update for the floating point patch. The 'g' argument for
printf() was implemented and a few bug fixes.
This is to be applied to the original source code, without the older
floating point
John Beckett wrote:
Bram Moolenaar wrote:
Here is an update for the floating point patch. The 'g' argument for
printf() was implemented and a few bug fixes.
I have compiled with this updated floating point patch under win32.
Here are some issues you might like to address.
os_win32
Mikolaj Machowski wrote:
Dnia Saturday 12 of April 2008, Tony Mechelynck napisa=B3:
On 12/04/08 20:29, Mikolaj Machowski wrote:
Dnia Saturday 12 of April 2008, Bram Moolenaar napisa=B3:
Here is an update for the floating point patch. The 'g' argument for
printf() was implemented
Bram Moolenaar wrote:
Here is an update for the floating point patch.
I've done a bit more testing with the latest floating point patch. Vim's
floating
point doesn't need to cover all extremes, but the following shows some bad
results.
:help floating-point-format (in eval.txt)
It says
On Sat, Apr 12, 2008 at 4:58 PM, Bram Moolenaar [EMAIL PROTECTED] wrote:
Here is an update for the floating point patch. The 'g' argument for
printf() was implemented and a few bug fixes.
This is to be applied to the original source code, without the older
floating point patch.
I would
On Sat, 2008-04-12 at 16:58 +0200, Bram Moolenaar wrote:
I would still like feedback on the format of floating point numbers:
123.456
1.23e-3
I don't understand the ampersand, why not something more mnemonic:
f123.456
.123.456
f.123.456
.f123.456
+123.456
--
Dnia Saturday 12 of April 2008, Bram Moolenaar napisał:
Here is an update for the floating point patch. The 'g' argument for
printf() was implemented and a few bug fixes.
This is to be applied to the original source code, without the older
floating point patch.
One thing:
let a = 1.2
let
On 12/04/08 19:57, Steve Hall wrote:
On Sat, 2008-04-12 at 16:58 +0200, Bram Moolenaar wrote:
I would still like feedback on the format of floating point numbers:
123.456
1.23e-3
I don't understand the ampersand, why not something more mnemonic:
f123.456
.123.456
On 12/04/08 20:29, Mikolaj Machowski wrote:
Dnia Saturday 12 of April 2008, Bram Moolenaar napisał:
Here is an update for the floating point patch. The 'g' argument for
printf() was implemented and a few bug fixes.
This is to be applied to the original source code, without the older
Dnia Saturday 12 of April 2008, Tony Mechelynck napisał:
On 12/04/08 20:29, Mikolaj Machowski wrote:
Dnia Saturday 12 of April 2008, Bram Moolenaar napisał:
Here is an update for the floating point patch. The 'g' argument for
printf() was implemented and a few bug fixes.
This is to be
On 12/04/08 22:29, Mikolaj Machowski wrote:
Dnia Saturday 12 of April 2008, Tony Mechelynck napisał:
On 12/04/08 20:29, Mikolaj Machowski wrote:
Dnia Saturday 12 of April 2008, Bram Moolenaar napisał:
Here is an update for the floating point patch. The 'g' argument for
printf() was
69 matches
Mail list logo
