Comments on: ROUND as native?
The round function is currently a mezzanine.
to see the code.
The cool thing is that it's polymorphic - it works over a range of datatypes.
However, with the addition of arbitrary precision math (the money! datatype), some difficulties occur. To get the correct results, Ladislav will need to export the denormalize function.
Another choice might be to make round a native action. The advantage is performance.
I'm voting for making it a native. It's a function you need a lot in business applications. So speed counts.
The other thing that is required is to have a really good and fast conversion from decimal! to string! (with thousand seperators etc.) and back.
Maybe this is a good candidate too.
Mezzanine code should be stable for a good period of time (say 2 years?) before being a candidate for native.
Or, at least, subject it to some rigorous testing by the community before nativing it.
And perhaps do both.
Bugs in mezzanines can be fixed by a growing pool of REBOL gurus. Bugs in native code has a much smaller talent pool.
Unless, of course, it is a open-sourced native.
Sunanda: I think, that your requirements are fulfilled, since the ROUND mezzanine has been stable for more than 2 years in R2 and became a subject to rigorous testing (an extensive ROUND test suite exists).|
I vote for making it native too.|
Ok, sounds like it should become native.
First, it needs to be correct.
1) How many people have complained about the current speed?
2) What are the use cases?
3) How much faster will it be as a native?
I'll be the first to admit that it's slow. Boy is it slow. Not only that, but the default case is the slowest because of the implementation. That said, how fast does it need to be? I use it all the time, though I've also avoided it in at least one case, because I knew it wasn't appropriate.
It's totally unsuitable for use where performance is critical and millions of calls to it will be made. That wasn't its goal of course. If you just need the behavior of TO INTEGER!, and performance is more important than the clarity added by the word ROUND, add a comment and don't use it.
Does making it native add value to REBOL? At this point, I don't think so.
I think that making it native is a good idea.
1) As a mezzanine it is currently too slow to be useful. Financial and numeric code would use it if it were fast enough. Regardless of its original purpose, functions like this are most useful in performance-critical situations.
2) The behavior is type-specific, and that is best done as an action!.
3) This is basically math, not REBOL's strong suit. Let C do its job where need be.
As long as the code is reviewable (or has a reviewable test suite), native code would be preferred.
Post a Comment:
You can post a comment here. Keep it on-topic.