After a long time having only partial floating point support in Red/System, it comes now to Red with a broader support, thanks to the terrific work from Qtxie and Oldes, who managed to push Red further while I was busy moving from Europe to China (though, this might be the topic for another blog entry, as requested by many of you).
float! datatype implements IEEE-754 64-bit floating point format. It is available with most of the usual math functions support:
add, substract, multiply, divide, power.
cosine, sine, tangent, arcsine, arccosine, arctangent.
log-2, log-10, log-e, exp, square-root, round
Note that these trigonometric functions are taking arguments in degrees, a
/radians refinement is provided for input values in radians. However, this can result in extra verbosity for some long math expressions where using only radians, like:
((sine/radians b) * (cosine/radians c)) + ((cosine/radians b) * (sine/radians c))
Some radians-oriented shortcuts to these functions are also provided for convenience:
cos, sin, tan, arcsin, arccos, arctan. So the above expression becomes:
((sin b) * (cos c)) + ((cos b) * (sin c))
Here are some code examples from Red console:
red>> 1.23456 == 1.23456 red>> 1e10 == 10000000000.0 red>> 1.23 * 2 == 2.46 red>> 1.23 * 2.0 == 2.46 red>> to integer! 1.23 * 2.0 == 2 red>> cos pi == -1.0 red>> sin pi == 0.0 red>> cos pi / 2 == 0.0 red>> cos pi / 3 == 0.5 red>> cosine/radians pi / 3 == 0.5 red>> cosine 60 == 0.5 red>> .1 + .2 + .3 == 0.6 red>> .1 + .2 + .3 = .6 == true red>> .1 + .2 + .3 - .6 == 1.110223024625157e-16 red>> float' load "0.1" == true red>> to float! 1 == 1.0 red>> 1 = to integer! to float! 1 == true
As you can see, Red tries to give you meaningful outputs even when the result is not exact, but this approach has its limits too. Qtxie has ported partially dtoa() functions to Red/System, however, the overhead of the additional code (20-40KB once compiled) is quite costly given how tiny is currently our runtime library (~350KB). So, for now, that implementation has been provided as an optional library for Red/System, and will be modularized for Red, once modules will be supported.
You might know that standard floating point format supports a few extra special values that are meant to make some calculation possible in edge cases. Those are also supported natively by Red, with the following literal formats:
Not a Number (NaN) : 1.#NaN Positive Infinity (+INF) : +1.#INF (or just 1.#INF) Negative Infinity (-INF) : -1.#INF Positive Zero : +0.0 (or just 0.0) Negative Zero : -0.0
These values are mostly intended for scientific calculations, you do not have to worry about them. They can be produced as results of some math operations on floats, but by default, an error will be thrown instead.
In case, you need to operate with maximum precision, and have all the special float values as results instead of errors, a couple of flags are available for that through the
system special access. The syntax is:
system/float-options [spec] [spec]: block of flags (word! | set-word!) with values (logic! | word!)
Valid flags are:
pretty': enables pretty printing of float numbers when very close to an integer value (default: true)
full': enables math operations on float special values (default: false)
So far, Red supported only the armel ABI for ARM backends. Since this release, we fully support now armhf ABI too, through a specific compilation option that can be found in the new RPi compilation target (intended mainly for default OS on RaspberryPi). The main difference between these ABI is the way float values are passed as arguments to functions, armel requires passing them on stack, while armhf requires passing them through FPU registers.
url!datatype preliminary support: all actions are working, but no path access support yet.
reverse, random, swap, take, to(*),
to is currently limited to integer/float/string conversions only.
After the digression in the floating point lands, we go back to our main roadmap, so in the next releases, expect (in no particular order):
Thanks for your patience and support during these last months, we are now back to our cruise development speed, so expect faster changes until the end of the year.
We have all waited long for this to happen, but it is finally there: first Red alpha release!
This is the biggest milestone since the initial release of Red System, as it marks the entrance of the higher layer of the Red software stack. There’s still another layer pending, the JIT compiler, but that’s for 2013, when Red will be self-hosted.
So what happened since the first Red compiler release a little more than a month ago’ We have added quite a lot of features actually:
block!, string!, char!, integer!, logic!, none!, word!, lit-word!, get-word!, set-word!, refinement!, action!, native!, op!, unset!.
make, form, mold, add, divide, multiply, subtract, append, at, back, clear, head, index', length', next, pick, poke, skip, tail.
if, unless, either, any, all, while, until, loop, repeat, foreach, forall, print, prin, equal', not-equal', strict-equal', lesser', greater', lesser-or-equal', greater-or-equal', not.
+, - , *, /, =, ==, <, >, <=, >=.
We also have some unit tests (223 tests right now), but that number should rapidly increase once we will be able to fully port QuickTest framework to Red (in a couple of weeks, once Red will gain functions).
All those features were mostly coded in the last month, some parts are still lacking (e.g. refinements support for actions/natives) but that gives you an idea of the pace at which Red will be further developed.
However, we haven’t started yet writting the documentation for Red language, we should decide soon on the kind of documentation we want (hint: you can make propositions about that on the Red mailing-list or FB page). Red API documentation will most probably be generated automatically from source code by extracting doc-strings.
A lot of things, but they will be added progressively until the end of the year, where we should have a pretty complete Red (bootstrap) implementation. So, the main pieces to implement are:
Red codebase is available at github, just clone it locally or download a packaged version. Some simple instructions to setup and run it can be found here. As we are still at the bootstrap stage, the installation process and usage is more complex than it should be, once self-hosted. Anyway, we should be able to deliver some test binaries soon and simplify the usage for those who want to play with the alpha releases.
Currently Red scripts are statically compiled using the
%red.r front-end wrapper. The Red lexer loads the UTF-8 encoded Red scripts in memory in form of blocks of values. Those blocks are then compiled to a Red/System script, that gets itself compiled to native code and outputs an executable binary. The Red/System compiler has been enhanced to be able to compile source code directly from memory.
Some compilation options are already available, the famous
-t option from Red System is also present, allowing Red to cross-compile any script as easily as with Red/System.
This is just the beginning, so for now, whole Red runtime library is compiled with user scripts each time. We will add modular compilation support at some point to get the full compilation speed back.
The missing characters in some of the screenshots are Chinese ones as I only have font support for them on Ubuntu.
Red was originally conceived to be statically typed. However, during the early stages of Red implementation, it appeared that an hybrid typing system will be more adequate for a language that will support high-level scripting, without the burden of a sophisticated, but slow, type inference engine. The overhead of such inference engine can be very high (cf Scala slow compilation speed ). The hybrid type system works very simply, typing is optional, but if local variables and function returned values are typed by user, the compiler will be able to generate faster code (more than an order of magnitude faster for, e.g., pure math expressions) and catch more programming errors at compile time.
Red compiler does not do any optimization so far, it basically outputs the equivalent of an unrolled interpreter loop. Some optimizations will be added along the development of the bootstrap version of Red, but the full extent of possible optimizations will be left for the self-hosted Red. Firstly because the current compiler code is disposable, so we don’t want to invest too much time in it, secondly because the final JIT compiler will allow even deeper optimizations thanks to reflection and profiling information collected at runtime.
Red/System has been improved significantly during the Red early development:
Red will now mature very quickly, as functions and objects will make their entrance in the next days/weeks. A new Red alpha release is planned very soon, probably for mid-november with a lot of new features.
The work on shared library generation for MacOS and Linux platforms is on-going. Once available, we’ll be able to literally “plug” Red in a lot of third-party apps, including other programming languages. Also, this will enable (or make easier) the bridging with some external systems like Java, .Net and objective-c, in order to fully support the main mobile platforms.