One of my guiding principles for Ioke is that I want to try to at least think through most of the parts of it, including things that most other languages have/don’t have. One of the decisions I made quite far back but haven’t written about concerns numbers. I have decided to go back to PL/I and COBOL with regards to real numbers. Well, that’s not the whole truth. I’m simply not going to have a representation of for real numbers in Ioke. Instead something like “101.1” will result in a decimal number. They will have infinite range in Ioke, and they will always be exact. To me it’s never made sense to have float and double in a general purpose programming language. Or, it makes sense from a performance perspective, but most of the time these types just bite us in the behind.
How many times have you seen numbers represented as float or double in C, C++, Java, C# or any of the other languages that include floating points? If you want to do scientific computation or non-discrete math, Ioke is probably not the right language anyway. But since it runs on top of the JVM you can write that part of your application in Java…
So, to recap, the type (which I might call ‘Decimal’ or ‘Radix’) will be exact. It will have potentially infinite range both in the magnitude and the fraction. Ioke will not have NaN or +/-Inf.
Also going back to other languages (such as Scheme and Smalltalk), Ioke will have a numerical tower. That means things like rationals will be in the language. So will integers of course (and yes, they will also have infinite range). I’m still thinking about complex numbers. They might be there, but falling back on my reasoning for not having floats in the language, having complex numbers seem kinda inconsistent. So probably not. I will have magnitudes, units and quantities, since these are extremely useful features in a language. That means money will be a combination of a ‘Decimal’ and a Currency Unit. There might be support for syntax here, in the style of Kawa Scheme (a quantity is a number directly followed by a unit name, without any whitespace: 100.2dollar, 5kg, etc. Obviously, there will be expanded ways of calling these, such as: Units Currency dollar(100.2), Units Mass kg(5). I haven’t decided on the exact hierarchy or syntax right now, but I know I will not build it from scratch. Instead I’m going to use gnu.math from Kawa.
So that’s my thinking about numbers for Ioke. The other details will be mostly natural things. I haven’t decided which bases should be literals, or if I can do something like Common Lisp with this. We’ll see. (And in fact, I haven’t even added numbers to the parser yet… They haven’t been necessary.)
12 Comments, Comment or Ping
>So, to recap, the type (which I might call ‘Decimal’ or ‘Radix’)
What’s wrong with ‘Number’?
Dale
October 6th, 2008
Dale:
Good question. I’ve thought about just having a unified number type, and I might still go down that route. It might actually prove to be easier for most use cases than having separate. (The names Decimal or Radix are based on there being an Integer type too).
October 6th, 2008
Having rational numbers is cool. And the idea of having infinite precision and magnitude is cool. What about having perfect precision irrational numbers? For example, is there a way to lazy-evaluate a composition of two irrational-number functions such that the outcome can be “any precision you want” at the end?
To be more specific with my example, suppose you want the square root of the cosine of x. Normally, you would evaluate the cosine of x and chop off the precision at some point, then pass the result to sqrt. But in haskell or other lazy-evaluated languages, it should be possible to compose two functions and then get the precision you want at the end, rather than during an intermediate step. Is there a possible implementation for Ioke?
October 7th, 2008
What about Fixed decimal (arithmetric) needed for financial calculations. Besides that I fully agree, it is rather frightening to see developers to readily accept woking in float or double and do all the rounding.
Not so sure about units, but perhaps with access to the AST it is not so limiting as one might think (i.e. Business Applications are usually much more meta driven, including tables for Currency or other Units). It just doesn matter, especially not when you dont address scientific computing.
October 7th, 2008
Bernd:
Fixed decimal arithmetic will not be any problem. It will be decimal and exact. I just want this to be the default and nothing else.
You don’t need to use the unit system. You can always build your own abstraction and use raw numbers. And the unit system will also be extensible with your own variations.
October 7th, 2008
Well, fixed decimals is not exact, it has an implicite round or truncation operation after each arithmetic operation based on the set precision/scale.
> bc
scale = 3
1 / 6
.133
Oh, while we are at it: if you add a somehow automatic conversation from Number to Text – the scientific notation should only be used if requested (%d vs. %e in C printf) – I hate this in the .toString() of BigDecimal in Java.
Java controls all of that with the MathContext of BigDecimal (digits/scale, rounding, form)
Gruss
Bernd
October 8th, 2008
Bernd:
Sorry, I shouldn’t say fixed (although I don’t know what the definition for “fixed decimal” is. Fixed point is the usual naming).
What I meant is that decimal arithmetic will be exact. Since I will have rationals in the language, 1/6 will be represented as such unless you do an explicit conversion to a non-rational number.
And yes, scientific notation is generally annoying. That will not be the default, I promise you! =)
October 8th, 2008
Yes, what I was pointing to is, that you might not want to have “exact decimal arithmetic” but “fixed point”. And to avoid operator overloading something like a math context is helpfull for that.
Of course the mathcontext could actually be a macro or some operator redefinition. It would just be nice to have that part of a language – especally in a business oriented DSL.
This would work nicely along with units (which would be kind of new type): “Dollars use a fixed point arithmetic with 3 digits and no roundup, the pretty-printer uses roundup to two digits”.
October 8th, 2008
I really like the idea of having support to units of measure in a language. I like the way this has been recently introduced in F#. Nice syntax, and “type checks” on operations… sounds nice.
Take a look: http://blogs.msdn.com/andrewkennedy/archive/2008/08/20/units-of-measure-in-f-part-one-introducing-units.aspx
October 10th, 2008
So, to recap, the type (which I might call ‘Decimal’ or ‘Radix’) will be exact. It will have potentially infinite range both in the magnitude and the fraction. Ioke will not have NaN or +/-Inf.
What’s 5/0 then? :)
October 15th, 2008
Pod:
Possibly an error. In many cases it doesn’t make sense to have that work. But if it’s an error, it can be handled specifically by the condition system I’ve described in this blog, which means the programmer can choose how to handle it. And actually, I’m thinking about reconsidering NaN and Infinity… Might be interesting to have them for some things.
October 15th, 2008
I’m coming to the discussion pretty late, but I really like what Duane Johnson said about lazy evaluation of irrational numbers to achieve any precision you want.
January 16th, 2009
Reply to “Numbers in Ioke”