Re: Updated floating point patch
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 -- Steve Hall [ digitect dancingpaper com ] --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
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) 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. --~--~-~--~~~---~--~~ 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 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 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 --~--~-~--~~~---~--~~ 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 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.20 (a Float IIUC) let b = string(b) let b = string(a) echo b 1.20 (a String IIUC) let c = eval(b) echo c 120 (a String = '1' . '20') 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? --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
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 applied to the original source code, without the older floating point patch. One thing: let a =1.2 echo a 1.20 (a Float IIUC) 1,20 type Float let b = string(b) let b = string(a) echo b 1.20 (a String IIUC) 1,20 type String let c = eval(b) E488, but something was done... echo c 120 (a String = '1' . '20') 1type 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. --~--~-~--~~~---~--~~ 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 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 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.20
(a Float IIUC)
1,20 type Float
let b = string(b)
let b = string(a)
echo b
1.20
(a String IIUC)
1,20 type String
let c = eval(b)
E488, but something was done...
echo c
120
(a String = '1' . '20')
1type 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.
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.20, which is
also the string-representation of an expression, gives 120 which
is the result of that expression -- a concatenated String. OTOH,
eval(1,20) gives an error Trailing characters because 1,20
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.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: GSOC: On-the-fly Code Checking for Vim - Challenges
Using a *built-in parser* is solution emphasized by Charles E. Campbell Jr in a related post. A parser would be perfect for syntax- checking, but I think the code checker should also detect errors like a misspelled library name. At least for C, you could use the clang C frontend ( clang.llvm.org ). It's a C frontend that uses a library design, so you should be able to use it in this project. As far as I understand, it can serialize its bytecode, so when the code is compiled for real, the parsing wouldn't have to be redone. If you could manage to create a flexible on-the-fly code checking system with an example code-checker for C based on clang (that'll also provide C++ and Obj-C support), that'd be quite useful. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
