Updated floating point patch
Bram Moolenaar
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 still like feedback on the format of floating point numbers:
&123.456
&1.23e-3
-
The psychic said, "God bless you." I said, "I didn't sneeze." She
looked deep into my eyes and said, "You will, eventually." And, damn
if she wasn't right. Two days later, I sneezed. --Ellen Degeneres
/// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///
Tony Mechelynck
> 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 still like feedback on the format of floating point numbers:
>
> &123.456
> &1.23e-3
>
I'm going to compile this after I send this mail.
The format of floating point numbers takes a little getting used to, but
IMO not as much as the hjkl cursor-movement keys. ;-) I'll have to read
attentively what has changed in the helpfiles: it may be more
advantageous to use ":echo printf('%g', float_var)" rather than just
":echo float_var" though it may depend on the defaults.
Best regards,
Tony.
--
Deliberation, n.:
The act of examining one's bread to determine which side it is
buttered on.
-- Ambrose Bierce, "The Devil's Dictionary"
Steve Hall
>
> 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
--
Steve Hall [ digitect dancingpaper com ]
Mikolaj Machowski
> 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.
>
let a = &1.2
let b = string(b)
let c = eval(b)
There is workaround with str2float but should be mentioned with
string() and/or eval() help. Also to eval() help could be added that it
works also with Lists and Dictionaries.
m.
Tony Mechelynck
> 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
>
>
The way I see it, it's to both avoid ambiguity and avoid breaking
compatibility:
1) f123.456 is the variable f123 concatenated with the constant 456
2) .123.456 is just as arbitrary as &123.456, and maybe more ambiguous
depending what comes before. Example:
:echo foobar .123.456
doesn't mean "echo the variable foobar separated by a space from the
number one hundred twenty-three point four five six" but "echo the
variable foobar concatenated with the strings '123' and '456' (with no
spaces since it is just one expression).
3) f.123.456 is the variable f concatenated with two strings - it
amounts to f concatenated with the string '123456'
4) .f123.456 (see 2); if preceded by a string it would concatenate the
variable f123 and the string 456 to it
5) +123.456 applies the concatenation operator to two numbers so both
are converted to strings and we end up with 123456 (the string '123456',
that is).
OTOH, with & there is no ambiguity because the various uses of & are
strictly separated:
&& is the "and" logical operator. Vim (unlike C etc.) has no bitwise
operator. The use of & in 'nomagic' patterns applies only in a strictly
delimited context.
&option (where the option name always starts with a letter) is an option
used as a variable, in the LHS of the ":let" command or as all or part
of an expression.
&number (where the number always starts with + - or a digit) is a
floating-point literal.
Best regards,
Tony.
--
ARTHUR: Ni!
BEDEVERE: Nu!
ARTHUR: No. Ni! More like this. "Ni"!
BEDEVERE: Ni, ni, ni!
"Monty Python and the Holy Grail" PYTHON (MONTY)
PICTURES LTD
Tony Mechelynck
> 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
echo a
1.200000
(a Float IIUC)
> let b = string(b)
let b = string(a)
echo b
1.200000
(a String IIUC)
> let c = eval(b)
echo c
1200000
(a String = '1' . '200000')
These are expected.
>
> There is workaround with str2float but should be mentioned with
> string() and/or eval() help. Also to eval() help could be added that it
> works also with Lists and Dictionaries.
>
> m.
Best regards,
Tony.
--
If ignorance is bliss, why aren't there more happy people?
Mikolaj Machowski
> 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
> >> floating point patch.
> >
> > One thing:
> > let a =&1.2
>
> echo a
> 1.200000
> (a Float IIUC)
1,200000 " type Float
>
> > let b = string(b)
>
> let b = string(a)
> echo b
> 1.200000
> (a String IIUC)
1,200000 " type String
>
> > let c = eval(b)
E488, but something was done...
> echo c
> 1200000
> (a String = '1' . '200000')
1 " type Number
I get different results. I strongly suspect localization (pl_PL)
-> , instead of . as separator.
> These are expected.
String isn't really expected. With fully working "translation" (as with
other data types) at the end should be Float.
m.
Tony Mechelynck
I use C locale, where the decimal point is a period. Evaluating the
string "2+2" gives the result 4, because the String has been evaluated
as an expression. Similarly, evaluating the String "1.200000", which is
also the string-representation of an expression, gives "1200000" which
is the result of that expression -- a concatenated String. OTOH,
eval("1,200000") gives an error "Trailing characters" because 1,200000
cannot be seen as ONE expression -- i.e., "when we're finished parsing
it, there's something left over", namely the comma and everything after it.
If you had used ":let c = str2float(b)" then (IIUC -- I didn't try) the
result would have come out equal to a. In a "decimal comma" locale,
eval('&' . b) wouldn't have worked, you would have had to first replace
the comma by a dot.
Best regards,
Tony.
--
For some reason a glaze passes over people's faces when you say
"Canada". Maybe we should invade South Dakota or something.
-- Sandra Gotlieb, wife of the Canadian ambassador to
the U.S.
John Beckett
> 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' in an attempt to make FEAT_FLOAT the default.
However, it doesn't work (FEAT_FLOAT is not the default) because in vim.h, feature.h
is included before os_win32.h (so HAVE_POW does not enable FEAT_FLOAT).
Two inconsequential compiler warnings occur:
eval.c (8482) : signed/unsigned mismatch
if (idx <= STRLEN(str))
ex_cmds.c (1912) : 'open' undefined
fd = mch_open((char *)tempname,
John
Mikolaj Machowski
> I use C locale, where the decimal point is a period. Evaluating the
> string "2+2" gives the result 4, because the String has been evaluated
> as an expression. Similarly, evaluating the String "1.200000", which is
> also the string-representation of an expression, gives "1200000" which
> is the result of that expression -- a concatenated String. OTOH,
> eval("1,200000") gives an error "Trailing characters" because 1,200000
> cannot be seen as ONE expression -- i.e., "when we're finished parsing
> it, there's something left over", namely the comma and everything after
> it.
>
> If you had used ":let c = str2float(b)" then (IIUC -- I didn't try) the
> result would have come out equal to a. In a "decimal comma" locale,
> eval('&' . b) wouldn't have worked, you would have had to first replace
> the comma by a dot.
I know all about that and don't call it a but (questionable) but this
should be explained in docs.
m.
Bram Moolenaar
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 patch.
> >
> One thing:
> let a = &1.2
> let b = string(b)
You mean: let b = string(a)
> let c = eval(b)
>
> There is workaround with str2float but should be mentioned with
> string() and/or eval() help.
I'll fix string() to put a '&' before a Float. That will fix it.
> Also to eval() help could be added that it works also with Lists and
> Dictionaries.
It mentions: This works for Numbers, Strings and composites of them.
List and Dictionaries are composites.
--
E M A C S
s e l o h
c t t n i
a a t f
p r t
e o
l
Bram Moolenaar
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.h now has '#define HAVE_POW' in an attempt to make FEAT_FLOAT
> the default. However, it doesn't work (FEAT_FLOAT is not the default)
> because in vim.h, feature.h is included before os_win32.h (so HAVE_POW
> does not enable FEAT_FLOAT).
Right. I'll change the condition in feature.h:
#ifdef FEAT_NORMAL
# define FEAT_EVAL
# if defined(HAVE_POW) || defined(WIN3264) || defined(MACOS)
# define FEAT_FLOAT
# endif
#endif
> Two inconsequential compiler warnings occur:
>
> eval.c (8482) : signed/unsigned mismatch
> if (idx <= STRLEN(str))
>
> ex_cmds.c (1912) : 'open' undefined
> fd = mch_open((char *)tempname,
I'll fix those. Unrelated to the floating point stuff though. Thanks.
--
"Never be afraid to tell the world who you are."
-- Anonymous
Bram Moolenaar
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 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 =3D&1.2
> >
> > echo a
> > 1.200000
> > (a Float IIUC)
>
> 1,200000 " type Float
>
> >
> > > let b =3D string(b)
> >
> > let b =3D string(a)
> > echo b
> > 1.200000
> > (a String IIUC)
>
> 1,200000 " type String
>
> >
> > > let c =3D eval(b)
>
> E488, but something was done...
>
> > echo c
> > 1200000
> > (a String =3D '1' . '200000')
>
> 1 " type Number
>
> I get different results. I strongly suspect localization (pl_PL)
> -> , instead of . as separator.
Hmm, that is a bit of a problem. In this context we really want the
1.234 form. Switching the locale completely might be a bit slow.
> > These are expected.
>
> String isn't really expected. With fully working "translation" (as with
> other data types) at the end should be Float.
See my other message.
--
Back up my hard drive? I can't find the reverse switch!
John Beckett
> 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 you can have negative number: &-0.123
:let a = &-0.123
Result: E112: Option name missing: &-0.123
:let a = -&0.123
This works but is inelegant.
str2float('1.75') works by converting '1' to 1 and '75' to 75, then combining them
(1 + 75/10^2). That gives a couple of problems. First, should probably document that
a 32-bit machine won't keep 15 digits of precision in something like
str2float('0.123456789012345').
Second, the lhs and rhs of the '.' can each overflow an integer, giving chaos.
:let a=str2float('0.3111222333')
:echo a
Result: -0.118374
In the next example, Vim calculates (-1 + 0.75).
:let a=str2float('-1.75')
:echo a
Result: -0.250000
Typo in eval.c ("sting" --> "string"):
Convert the sting "text" to a floating point number.
John
Yakov Lerner
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 still like feedback on the format of floating point numbers:
&123.456
&1.23e-3
When left operand is number, can you require
space around '.' concatenation operator, otherwise '.'
is floating point ? Who needs concatenation of two constants anyway ?
123.456 " floating number
123 . 456 " concatenation of "123" and "456"
123. 456 " floating number 123. concatenated with "456"
123 .456 " integer 123, space, floating .456
123.e2 " floating number
123 . e2 "concatenation of number and variable
123. e2 "floating number, space, variable e2
123 .e2 "concatenation
?
Maybe backward-compatibility option for that ? (treat 123.456 as concat vs
floating ?)
Yakov
Yakov Lerner
> 123. 456 " floating number 123. concatenated with "456"
123. 456 " floating number 123. , space, integer 456
Zdenek Sekera
Sorry for pre-posting but it is difficult to post-reply to an HTML text.
(Do we need HTML for emails???)
Anyway, somehow it seems to me this feature is a solution looking for
a problem. For a long time the good (not necessarily liked) principle was
to add a feature (and I like features!) when it is demanded/useful, not
simply nice-to-have. Well I don’t think this has ever been seriously
requested in any vim polls-for-features.
Well, it’s here, hallelujah.
But I am very uneasy with that leading ampersand. That’s so different
from any usual writing so it’s looks somehow bizarre to me.
There are human languages where a floating is not necessarily
written with a dot but with a comma, like this ‘1,71’. Not very
transparent to those not used to it but it can be done. I had
to learn the dot notation coming from the comma, took me short
while before becoming natural, so I supposed it shouldn’t be
a big problem going the other way around.
So ‘let a=1,72+1,98’ (no apostrophes of course) may not look so obscene
after a while to anybody. Even Windows and Linux OS/applications
can be configured to print floating with commas by default, can’t they?
How would this change complicate the vim parser? Have I overlooked
some obvious reason why this couldn’t be considered?
Cheers,
---Zdenek
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
Jürgen Krämer
Hi,
Zdenek Sekera schrieb:
>
> But I am very uneasy with that leading ampersand. That’s so different
> from any usual writing so it’s looks somehow bizarre to me.
I don't like the leading ampersand, either.
> There are human languages where a floating is not necessarily
> written with a dot but with a comma, like this ‘1,71’. Not very
> transparent to those not used to it but it can be done. I had
> to learn the dot notation coming from the comma, took me short
> while before becoming natural, so I supposed it shouldn’t be
> a big problem going the other way around.
>
> So ‘let a=1,72+1,98’ (no apostrophes of course) may not look so obscene
> after a while to anybody. Even Windows and Linux OS/applications
>
> How would this change complicate the vim parser? Have I overlooked
> some obvious reason why this couldn’t be considered?
Yes; commas are used as argument separators in function calls. With a
comma as decimal separator you wouldn't know, if
:call MyFunc(123,456)
call MyFunc() with two integer or one floating-point arguments.
jkr
--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)
Zdenek@gmail
> -----Original Message-----
> From: vim...@googlegroups.com [mailto:vim...@googlegroups.com] On
> Behalf Of Jürgen Krämer
> Sent: 14 April 2008 10:09
> To: vim...@googlegroups.com
> Subject: Re: Updated floating point patch
>
>
>
> Hi,
>
> Zdenek Sekera schrieb:
> >
> > But I am very uneasy with that leading ampersand. That’s so different
> > from any usual writing so it’s looks somehow bizarre to me.
>
> I don't like the leading ampersand, either.
>
> > There are human languages where a floating is not necessarily
> > written with a dot but with a comma, like this ‘1,71’. Not very
> > transparent to those not used to it but it can be done. I had
> > to learn the dot notation coming from the comma, took me short
> > while before becoming natural, so I supposed it shouldn’t be
> > a big problem going the other way around.
> >
> > So ‘let a=1,72+1,98’ (no apostrophes of course) may not look so
> obscene
> > after a while to anybody. Even Windows and Linux OS/applications
> >
> > How would this change complicate the vim parser? Have I overlooked
> > some obvious reason why this couldn’t be considered?
>
> Yes; commas are used as argument separators in function calls. With a
> comma as decimal separator you wouldn't know, if
>
> :call MyFunc(123,456)
>
> call MyFunc() with two integer or one floating-point arguments.
Right, obvious, forgot about that!
---Zdenek
Bram Moolenaar
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 (in eval.txt)
> It says you can have negative number: &-0.123
> :let a = &-0.123
> Result: E112: Option name missing: &-0.123
> :let a = -&0.123
> This works but is inelegant.
I'll fix that.
> str2float('1.75') works by converting '1' to 1 and '75' to 75, then
> combining them (1 + 75/10^2). That gives a couple of problems. First,
> should probably document that a 32-bit machine won't keep 15 digits of
> precision in something like str2float('0.123456789012345').
>
> 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?
> In the next example, Vim calculates (-1 + 0.75).
> :let a=str2float('-1.75')
> :echo a
> Result: -0.250000
I'll fix that.
> Typo in eval.c ("sting" --> "string"):
> Convert the sting "text" to a floating point number.
I'll fix that.
--
You were lucky to have a LAKE! There were a hundred and sixty of
us living in a small shoebox in the middle of the road.
Charles E Campbell Jr
> 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 still like feedback on the format of floating point numbers:
>
> &123.456
> &1.23e-3
>
I have an alternative format:
123;456
ie. use semicolons instead of the ".". If the printing of them also
uses semi-colons, they'll be a bit less likely to cause problems:
let a=12;34
echo a
12;34
let b=string(a)
"12;34"
let c=eval(b)
12;34
I admit that I'm not sure if I like semi-colons better than the leading
& myself -- although a semi-colon does have a "." of sorts embedded in it.
Regards,
Chip Campbell
Mikolaj Machowski
I suggested it few days ago :) But it they are possible conflicts with
list unpacking.
:help let-unpack
:let [a, b; rest] = ["aval", "bval", 3, 4]
m.
John Beckett
>> 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 have produced the attached alternative. I've given it a reasonable test, but I
haven't bothered fully studying it because you might want to do it another way.
This patch applies to Vim 7.1 with patches 1-293 and Bram's last floating point
patch (2008-04-13). It fixes all the problems I mentioned.
John
Bill McCarthy
> This patch applies to Vim 7.1 with patches 1-293 and Bram's last floating point
> patch (2008-04-13). It fixes all the problems I mentioned.
It looks good. The nines problem is solved and numbers can
now start with signs - nice.
--
Best regards,
Bill
Ben Schmidt
> 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
is invalid. Not sure whether that's desirable. Probably the lesser of two evils.
Of course, it needs to be enforced that printf and such functions either omit the
ampersand for floats which happen to be integers (probably undesirable) or always
append a '.0' in this case.
Would wrapping floats in braces be a better syntax? I don't think this would clash
with anything: dictionaries require keys followed by colons which don't occur in
floats, and a float is also an invalid variable or function name due to starting
with a digit or sign (+/-) so couldn't be used as part of curly-brace variable or
function names. E.g.
:let myfloat={12.52}
:let mybig={1234e56}
:let myintegerfloat={123}
To me, this is nicer than a leading &, and avoids the nasty restriction of needing
a decimal point all the time/ambiguity of decimal point vs. concatenation.
Ben.
Ben Schmidt
Actually, to clarify, my proposal is that a set of curly braces is taken to
represent a float if and only if it is (1) not preceded by a valid variable name
character and (2) contains a valid float.
I.e. floats:
{+123.456}
{-123}
{123e-4}
{123.456}something_to_concatenate
non-floats:
{dictionary: 'value'}
variable_name_with_number_{123}
variable_name_with_number_and_variable_e_concatted_and_included_{123e4}
variable_name_with_six_digits_here_{123.456}
{variable_name_from_a_variable}
{10<x?'variable_1':'variable_2'}
combination!:
variable_name_with_float_expression_giving_{{0.55}<some_float?'true':'false'}
variable_name_with_float_that_prints_as_integer_{{123}}
invalid:
variable_name_with_punctuation_due_to_float_{{123.456}}
I think it works unambiguously and sensibly, though, of course, you can still do
dumb things if you try hard enough! But I don't think it breaks anything that
currently works (even if what currently works is dumb)!
Ben.
Charles E Campbell Jr
echo x{1.2}
Works quite nicely -- and is ambiguous with respect to floating point
overloading.
Regards,
Chip Campbell
Charles E Campbell Jr
[a-zA-Z:_<>]).
Regards,
Chip Campbell
Ben Schmidt
No, it isn't ambiguous. By (1) of my definition, this is not to be interpreted as
a float. Furthermore, a variable with name 'x1.2' is invalid. A more confusing
example would be
let e=3
let x132=4
echo x{1e2}
but it still isn't ambiguous by my definition.
Ben.
Ben Schmidt
Cheers.
My later reply to your earlier message was written only because this one
hadn't arrived in my inbox at that stage.
Smiles,
Ben.
Charles E Campbell Jr
and x12 is not invalid. But, as you said, the {} in my example is being
preceded by a valid variable name character, so my objection is nullified.
Regards,
Chip Campbell
Ilya Bobir
> [...]
>
> 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 find only 39 matches and all where false positives.
Here is the query:
And here is a regex I've used (along with explanations). Maybe someone will
double check to make sure I did not mistake.
lang:vim | Vim script language.
^\s*[^"\ ] | In order to exclude comments the line should
| start with anything but ".
( | Catches different kind of strings.
" ( \\. | [^"] )* " | Double quoted strings along with escapes
| inside the string.
| ' [^']* ' | Single quoted strings.
| [^"] | All the rest is OK. And there maybe some
| staff preceding the digits.
)* |
\s\d+\.\d+\s | A pattern that I was looking for - two numbers
| concatenated without an interleaving space
| that are not part of a longer sequence.
-menu | menu command uses dot separated numbers to set
| priority. There are plenty of them and all
| are false positives, so remove all lines with
| "menu" string in them.