Float math extension

For no other reason that it being the first to come to mind, I implemented a small floating-decimal numbers extension (as opposed to integers). Implementing it was helped me realize what the current virtual machine still lacks and how it can be better implemented.

For example, the Object class from which everything is introduced contained a toString() method. There are a number of languages that have some form of a toString() method. In C++ this only works for constant character strings, which is the original design intention. The number class for the virtual machine stores strings because it makes for a simple printing function as well as easy integration with large number libraries such as GNU MP. However, my extension objects shouldn’t need to hold a constant string. That’s a waste of memory (not to mention, it has to be synchronized with the rest of the data). To solve this, I created a writeToString() method, but since I don’t want a confusing interface, I’ve removed the toString() method.

That said, I will also be adding methods such as writeToInt() and writeToDouble(). Couldn’t I just return the values directly in this case? Yes, but in this case, these methods will return a boolean value that indicates whether such an output was even meaningful. For instance, converting a function to float doesn’t make any sense, and a warning message should be given if the user attempts to do this. Since warning messages aren’t emitted by the actual function class, a writeTo[something] method can return false if the conversion is not meaningful. As strings are always meaningful in some way (e.g. functions return “{fn}”), there is no return for writeToString().

It is important that extension-creators know this because I expect them to use this interface. It is, admittedly, slightly tedious in certain situations. However, this is shorter and cleaner than the alternative I was using: downcasting simple primitive type wrappers. Wrappers for more complicated types will still need to be downcast unless I figure out a way of extracting data from complex types without bloating the Object class interface.

~ Floating Point ~

The floating-point number extension contains a single data type (“Float”) and some functions for processing. Each of these functions uses writeToFloat() for obtaining numeric values, so naturally, they are tailored to optimizing usage of the Float object.

  • create – Creates a Float object.
  • sum – Adds all numeric parameters.
  • dif – Subtracts all remaining numeric parameters from the first parameter.
  • mul – Multiplies all numeric parameters.
  • div – Divides the first parameter by all remaining numeric parameters.
  • pow – Uses the first parameter as a base and all remaining numeric parameters as exponents.

Each of these functions can be aliased a different way. For example, the “create” extension can be aliased as “Float”, the “sum” as “Float_sum”, etc.

As expected, they give warnings for the usage of invalid parameters. This requires, however, that they be given a pointer to a class implementing the Logger interface.

As with many functions in Copper, they can accept a variable number of parameters, though there are limits as to what the VM itself can handle.

To make adding them to the engine easier, I created a convenience function that gives them either specific names (“Float_sum”, “Float_dif”, etc.) or generic short names (“Sum”, “Dif”, “Mul”). I intend to do this with the other extensions and try to set a precedence for future extensions. By having two different options for aliases for multiple number-handling extensions, a programmer can use any one of them as a drop-in-replacement when using the generic short names while forcing the usage of a particular one in the case it is desired. This is useful in cases such as incrementing, where you definitely want to use an integer.

The naming convention itself – sum, dif, mul, div – doesn’t exactly please me. I’d prefer ‘+’, ‘-‘, ‘*’, ‘/’, but there are some issues using these names. Making these characters be valid for names would allow names such as “+1”, “-2”, “vec+vec”. While some names might be useful, I feel like they are ambiguous. That’s not to say anyone who uses this virtual machine can’t set the names to those (though, at the current time, they will need to modify the VM to allow those characters), but for now, I prefer alphabet names only. Whether Unicode will be allowed is still up in the air. Notably, having short names is also bizarre. “div” isn’t very descriptive. The names stand for, respectively, “summation”, “difference”, “multiplication”, “division”, and “power”. Writing those out is tedious, hence the short names. I didn’t use “add” or “sub” because “sub” is ambiguous and “sum” is more indicative of the fact that you can add multiple parameters (not just two).

~ Concluding Remarks ~

Implementing the extension was very easy. I’m glad I chose using a class interface for foreign functions rather than require that functions and methods be statically wrapped and parameters be limited to what the function can take (as is the case in AngelScript and Neko). It’s more flexible, and suits the language.

While on one hand, creating an entirely new class just for a single command seems like a waste of space, the fact is that we create tons of class instances in other programming languages without blinking an eye. Just think of how many objects you create in JavaScript.

The FFI is still rough, however. I may jump straight to implementing extension functions that handle complex data types just to see how I might be inspired to optimize them.

The name situation has not been fully resolved. Whether names that include ‘+’, ‘-‘, ‘*’, and ‘/’ will be allowed is still in question. Polite opinions and suggestions are welcome.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s