> 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 (fifth root of 32). - float2nr(nan) gives -2147483648, which I think is fair enough (indeed, quite a clever solution, I think), but isn't documented. - Related to this: Would you consider using the same values for Numbers? i.e. -1/0 => -2147483647 and 0/0 => -2147483648 as well as the current 1/0 => 2147483647. That would make a *lot* of sense, and make Numbers and Floats inside float2nr() behave consistently. And since there is a small chance this could break compatibility (though surely few scripts would rely on this behaviour), 7.2 would be a good time to make the change. (It wouldn't be perfect as Numbers don't have a negative zero, but it'd be as good as possible within the realm of Numbers.) >> - The neater display is nice. IMHO it would be better to show full >> precision when this is there. I.e. it's great that :echo 2.7 shows >> just 2.7. But it'd be great if :echo 2.718281828459045 showed that, >> rather than just 2.718282. I guess this depends on printf, and so may >> not be possible (I can't get it to work in Vim at present, doing %.16g >> and %g loses it's nice truncation of zeros property), but it would be >> nicer, I think, if it is easily possible. > > printf() uses a default precision of 6. I think it's OK for a default, > showing more is mostly not useful. The problem I have with only showing that much is that it gives the (false) impression that Vim is only using single precision. So... - Here is at least another documentation deficiency. Although precision is mentioned and related to the 'library Vim was compiled with', it doesn't mention that 'double' is used. That would be good to fix. - 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. - 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 maximum precision output can be obtained with %.15g. >> - 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 use for them. I don't know how many users are like me, but there >> must be a few as surely programming is fairly closely related to >> mathematics in many ways. (I'd like exp() and log() as well, but these >> can be done with pow() and log10() by appropriately defining e, so not >> an issue. tan(), sgn(), rand(), etc. are easy with scripts, too, so no >> problems there.) > > log10() is there. I don't see a use for sin() and the like. If you > really want these please come up with an example. The most classic example surely has to be conversions between polar and rectangular coordinates. This needs to happen a lot when doing GUI work inolving circles (e.g. drawing a clock face or implementing some kind of spinning progress indicator), editing data files with coordinates (e.g. for mapping applications or a flight simulator). Sometimes these are one-off calculations that you want just to hard code a constant into code or such; other times you want to convert a list of figures, and it'd be great to just be able to whack qq and with a bunch of yanks, <C-r>= and so on, hack together a macro to do it quickly in Vim. Though I hate to say it...these functions would probably be most useful if they worked with degrees not radians. However, for accuracy, it would definitely be best just to use the C library functions, which basically use processor instructions, rather than having Vim add additional computations of its own (so as long as you're not using one of those early Pentiums...). deg2rad() and rad2deg() are easy to implement in scripts with an appropriate definition for pi, but perhaps since the more useful applications for programming are with degrees, it'd be worth including them as Vim functions--then the more useful case is easily accessible out of the box without sacrificing accuracy and thus crippling its use for more scientific applications. For that matter, could we define v:e and v:pi? v:e=2.718281828459045 v:pi=3.141592653589793 They would be useful. Not essential, though, as easy to do in a script (well, with g: variables rather than v: ones though--or with functions that return them). >> - Actually, though, an abs() function may be worth implementing, the >> reason being that with floats you often need to compare with a given >> precision to make it work. Since often computations will result in >> slightly different numbers, the == operator is not adequate, and you >> need to do something like abs(a-b) < 1.0e-9 as a kind of >> 'approximately equal to' instead. > > It's useful. I suppose we can make it work for both Float and Number, > without changing the return type. - You mean returning the same type that it's fed? That sounds like a great idea to me. - I wonder whether it's smart to make ceil, floor, round, trunc behave like that, too? All of them return a Number unchanged. - And another documentation one: I guess the job of a nr2float function is filled by str2float. However, it *looks* like an omission because it's not listed under 'Floating point computation' in the function list. Perhaps list it there as well as under 'String manipulation' with a note that it can be used on Numbers? - It may also be worth noting at the str2float documentation that feeding it a Number (or variable holding one) works because of automatic Number->String conversion. Ben. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
