Number type

[jonathandavid]

Hi,

I've read that it is possible in Cobra to use the type "number" to refer to a decimal, and that this can be changed with a compiler flag, so that number defaults to float64. That seems like a good idea to me. However, I have doubts about the use of the term "number", as to me an "int" is a number as well. Therefore, I would find confusing to have a method like this:

def f(x as int , y as number)
...

To me, both x and y are numbers, so this signature gives me little information. For that reason, I would prefer the term "real" instead of "number". This way the same function would be more informative, as it is clear that x is an integer where as y is a real number.

def f(x as int , y as real)
...

Another type system that would work for me is this one:

real32: floating point real, 32 bits
real64: floating point real, 64 bits
bigreal: unlimited precision real
real: bigreal by default, real32/64 with compiler flag

This way we avoid the int/number confusion, and we use only one term (real) as opposed to three (float/decimal/real or float/decimal/number).

For simmetry, it would be nice to have:

int32: integer, 32 bits
int64: integer, 64 bits
bigint: integer, unlimited size
int: bigint by default, int32/64 with compiler flag

I understand than having all ints be bigints by default could slow things down a bit, but the same could be said about imposing decimal as the default type for "number". Also, I'm aware than biginit is not currently supported in Cobra, but that shouldn't be a problem as there are seem to be several C# implementations on the net (and BigInteger is planned for inclusion in the next .NET, in fact it was planned for 3.5 but they removed it in the last instant).

Regards,
Manuel

[Charles]

I shied away from "real" because in my mind it implies the union of both rational and irrational numbers. But I can see how "number" is also not a perfect term as you pointed out. Regardless of which term you use, you might always run into a confusing signature such as:

def foo(a as float32, b as real)

In any case, I'm familiar with using "real" in Pascal and somewhat open to the idea. What do others prefer for the type name? I'll make a poll.

I hadn't considered "int" being a type alias assignable to something else. I see nothing wrong with that idea.

Now regarding the default types...

One of Cobra's goals is that a Cobra developer can hand over a class library (via .dll or .class) to a C#, VB or Java programmer (depending on what platform you're on) who will be able to use the class library both technically and comfortably. Additionally, Cobra has the goal of being nearly as fast as C# and Java.

For these reasons, Cobra favor types such as "int" and "decimal". And while "decimal" may be slower than "float64", it's fixed size and system implementation mean that it should run reasonably fast.

Of course, your Cobra class library might be less comfortable for other developers if you make use of redefining the default numeric types, but presumably you do that when you need it and would have used them anyway. At least the default types in Cobra are both fast and easily worked with.

[jonathandavid]

Chuck: I've seen the poll, thanks for considering my suggestion.

As you know, however, the poll only addresses my proposal in part, as it had in fact more to do with having a complete "real" family, as in:

real32 for float32

real64 for float64

real for .net decimal (customizable via compiler flag)

(maybe) bigreal for unlimited precision fractionals

This way two problems were adressed:

1) confusion between number and int

2) excessive number of related terms (float, real, decimal) which in my opinion is undesirable in a language that strives for clarity and readability

I see that you've discarded this possibility, in favor of considering only a more conservative one (replace only number with real). That's perfectly OK with me, it was only an idea after all. If possible, however, I would like to know the reason behind your decision (e.g., "doing it would break too much existing code").

Also, it would be nice to know what everybody else things about this issue.

Regards,
Manuel

[Charles]

You're correct -- I glossed over the real32/real64 part. These types are called "floating point" in C#, Java and IEEE. See:

http://msdn.microsoft.com/en-us/library/ya5y69ds(VS.80).aspx
http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html
http://en.wikipedia.org/wiki/IEEE_754

And also in C, C++, Python and Ruby. "Floating point" is a very specific term with implications about that type:

http://en.wikipedia.org/wiki/Floating_point

I therefore find it really difficult to call it anything else. And while making the names more similar would give the appearance of unification, it would be technically misleading.

Also you wrote "real for .net decimal (customizable via compiler flag)" but that implies that customizing that type to say "real64" would make decimal unavailable. My intention with the numeric types is that you can name any of them at any time. Redefining real/number should not leave any type, such as decimal, unavailable.

One could make a language that truly unifies the numeric types along with other purities such as unifying class/interface, etc. But Cobra stays a bit closer to the hardware and a lot closer to C#/Java than say Python and Ruby do. It also runs tens to hundreds of times faster than those languages making it suitable for a wider range of applications such as AI, financial analysis, video game engines, multi-core processing, etc.

[jonathandavid]

I have to agree with what you say, thanks for explaining. I've been thinking about other alternative naming schemes and, all things considered I can't think of a better one than float32/float64/decimal (I never liked the use of "double" in the C++/Java/C# family of languages: "double what?"). It's also great that you introduced the alias float for float64, it would be a pain to see my programs populated with "float64" everywhere (I do computer graphics in C++ and use doubles for everything)

Regards,
Manuel

[Charles]

Yeah I hate "double" and "long" as well. They're arbitrary.

In general, a single adjective makes for a poor type name.

[jonathandavid]

I shied away from "real" because in my mind it implies the union of both rational and irrational numbers.

I've been thinking for a while about this argument against the use of "real" as a type name.

My conclusion is that "real" is OK, as it implies that the type is an approximation to a real number, which is precisely what it is.

If you think about it, it's the same with "int". Nobody would expect an "int" variable to be able to store every conceivable integer (think of 10^(10^10)), but the term "int" is used nevertheless because the type represents an approximation to an integer number, with some range restrictions. So just like an "int" represents an integer with range restrictions, a "real" would represent a real number with range *and* precision restrictions.

Another argument in favor of "real": every programming language seems to use the type "complex" for complex numbers, even though a "complex" in thouse languages will never be able to store a complex number like (pi + e*sqrt(-1)). People simply understand that a "complex" is an approximation to a complex number, and they are perfectly OK with. It should be the same with type "real" in Cobra.

Chuck: please feel free to move this post to the "real vs number poll" thread if you think it belongs there.

Regards,
Manuel

[Charles]

These are good points.

You can repost this on the other discussion thread if you like. I looked for a "move" as an admin, but couldn't really find it. Just a split for creating a new thread.

[hopscc]

Perhaps its in the way you're thinking about it
int/float/decimal are numeric types
number is a placeholder for a (generic) numeric type (non integer type currently) to be specified at compile time
( in lieu of doing anything special at compile time 'number' is the same type as 'Decimal')

def f(x as int , y as number)
...

To me, both x and y are numbers, so this signature gives me little information.

Hmmm
both are 'numbers in the mathematical sense ( as are any/all of int*, float*, decimal, number...)
In terms of a program 'x' is an integer and y is a generic non-int numeric type (probably decimal), exact typing to be defined later.

as it is clear that x is an integer where as y is a real number.

You say a real number, I say a real number ( Tomayto/Tomarto)