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).
Please, please don't start thinking of all kinds of things we can add to
Vim. There is no end to it. And for every feature one can come up with
there is always someone who can think of a use for it.
The use of adding floating point support is discutable anyway. I think
just adding basic operations, which are very likely needed once you have
floating point numbers, is all we should do at this point.
For example, round() can convert a float to an int. It makes sense to
add that: after using floating point computations to avoid roundoff
problems you want the resulting number (e.g., a percentage).
I think we don't really need the others:
floor(f) == round(f - 0.5)
ceil(f) == round(f + 0.49999)
trunc(f) == f > 0.0 ? round(f - 0.5) : round(f + 0.5)
I can't remember ever needing trunc(), I find it acceptable it's a bit
complicated.
> >> 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'.
It looks like a problem with the FreeBSD include files.
> There is still a bug there, though:
>
> :echo -1/0 " gives 2147483647, see below
> :echo 0/0 " gives 2147483647, see below
This is as specified. It's better than crashing, don't expect a valid
result.
> :echo -1.0/0 " gives inf, should give -inf
> :echo 0.0/0 " gives inf, should give nan
The "inf" and "nan" values are not defined for Vim.
> 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.
I really think we can do without most of these. Vim is not a
mathematical calculator. One that can be useful is log10(f), since it
gives an indication of the length of the number/float converted to a
string. Although you could do it with len(printf('%f', f)).
> >> 4. Cosmetic thing but truncating of 0s in floating numbers would be user
> >> friendly (eg. store and display 0.5 instead of 0.500000)
> >
> > I don't see an argument to printf() to get this.
>
> Yeah, that'd be a good improvement.
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.
> 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.
Double is used, as floats are often converted to double anyway when
using math functions and operators.
--
How To Keep A Healthy Level Of Insanity:
2. Page yourself over the intercom. Don't disguise your voice.
/// 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
-~----------~----~----~----~------~----~------~--~---
