Proposal of new datatype: complex!

[rebolbot]

Submitted by: giuliolunati

Could be modeled on pair!, with different multiplication rule. Syntax: i e.g 3.5i-6

exp log sine arcsine etc. must be extended to accept complex! values

>> 3i4 * 0i1
== -4i3
>> exp 0i3.1415927
== -1

^{CC - Data [ Version: r3 master Type: Wish Platform: All Category: Datatype Reproduce: Always Fixed-in:none ]}

[rebolbot]

Submitted by: BrianH

We have a very limited budget when it comes to built-in datatypes: 64 altogether, including internal ones. So, every built-in datatype we add has to be really worth it. What would this type gain us? I mean, in syntax. We can do the math without the syntax. It would be add-on functions, but we could do it. So, what would adding the syntax give us?

Due to Rebol's evaluation model, its main strengths are in structure manipulation and textual and binary data handling, mostly because these types of things involve fewer large-scale operations, which minimizes interpreter overhead. What it's not really as suited for is basic math - we can do it, but it's not as fast as in compiled languages because these are small operations which have to be combined in large quantities, and that maximizes interpreter overhead. Because of this, the kinds of calculations of which I'm aware of needing complex numbers are not likely to be done in Rebol even if we add native support, and the types of people who use complex number syntax aren't likely to choose a language that is not specifically optimized for numeric calculations (like NumPy or Matlab). But there may be non-scientific reasons to use complex numbers, uses that I'm not aware of.

So what does this give us? How does adding this syntax improve our dialects? There's a plan to add user-defined datatypes - we even have a built-in type reserved for this, utype!. This would allow us to add new datatypes which respond to the actions, which would allow us to even have them support math operations if necessary. The only thing you wouldn't get is custom (non-construction) syntax for the type, or the ability to fit in a value slot.

So, this means that the main thing that adding a real datatype can give us is to have a custom syntax, or to fit into a value slot so it can get the pass-by-value semantics. But you can't fit two 64-bit numbers in a value slot in 32-bit Rebol, and we want 64-bit Rebol to be compatible with 32-bit Rebol. Doing complex math with a single value slot for both numbers means that you have reduced precision for those operations, so not having a datatype and using two value slots with decimal! in them would be better for its semantics. Pairs are made for coordinates, it's OK for them to have reduced precision (32-bit numbers). You could make the value a structure, pointed to by the value slot, and try to fake the immediate semantics, but that would require adding support for a new structure type to the memory manager and garbage collector, and all operations on complex values would be slower because they would require extra pointer indirections and allocations, and cache misses.

So the only advantage to making this a datatype would be the syntax, and syntax only matters for dialects. What dialects would this enable, and are they likely to be commonly needed in the types of applications that Rebol is likely to be used for? This is a genuine question: Saphirion makes analysis software, for instance. Can these applications be served by a compiled language with string source, which compiles to a semantic model suitable for numerics? That's actually easier to add than a new datatype, and can even be in an extension, so we don't have to include it when we don't need it.

Datatypes are not optional, every one we add needs to have wide use to make the cut. All of the ones in there have general use, or serve as minor syntactic distinctions on common underlying semantics, which makes them really useful for making more flexible dialects. We even dropped a couple from Rebol 2 because they had to make room for others, or were no longer a good idea (the list! type is cache-hostile). If it's at all possible to not add a datatype, or especially to have your stuff done with a module, a port scheme, an extension, or even a utype once we have them, then you should seriously consider that instead.

Nonetheless, I'm not aware of any syntax conflicts with that syntax (anyone else?), so if we do decide to add it then it should be possible. Maybe for Red, it's compiled so it's more likely to be usable for numerics.

[Oldes]

Why is this wish labeled as important?

[hostilefork]

Pre-import of CureCode, in 2014 BrianH changed the "severity" from minor=>major, which most likely was translated in the tag system to "Status.important".

https://www.curecode.org/rebol3/ticket.rsp?id=2137

Perhaps in his thinking of "severity" this seemed like it would be a very major change. And a very-major-change-wish became "important" in the import logic.