[29]> (integerp (/ 3 1))
T
[30]> (integerp (/ 3 2))
NIL

Irrespective of the fact that all the numbers involved are subtypes of
rationals, this is still different from the behavior of most commonly used
programming languages (including dynamically typed ones) where the result type
of mathematical operations is completely determined by the types of the
parameters. That CL deviates from this common behavior would seem to make it
easier to write abstract numeric code, but one can at least imagine some
disadvantages. For example the fact that most languages will signal an error
if one attempts something like (sqrt some-negative-float) might also help to
find errors due to bugs or numerical roundoff in some cases. Other potential
issues are efficiency (e.g. due to converting back and forwards between
different internal representations), problems with different storage
requirements, and the behavior of arrays or matrices (e.g. how should division
of the elements of a matrix of integers through an integer behave?). In
addition and expression that evaluates to a float in one implementation might
return a rational in another, which could lead to compatibility problems. I
don't know what other things somebody might come up with, but I guess you get
the idea.

I'd like to know whether CL programmers who have written quite a bit of
numerical code feel that CL's number system is just better than what's on
offer in most or all other programming languages for almost any situation or
whether there sometimes are problems/bugs that wouldn't occur in say python or
whatever.

Also, CL is not completely consistent in the approach that mathematical
subsets of a certain group of numbers are just treated as special cases of
this group (e.g. reals are not a subtype of complex and #c(1.0 0.0) and 1.0
behave rather differently, so it is for example not possible to compare the
magnitude of the former to another number; but then #c(1.0 0) isn't of type
complex and eql to 1.0).

I'd be interested to know what the rationale for these decisions was.

Mathematicaly (complexp 1) ==> T would seem more intuitive and in scheme which
has, I think, a similar number model (complex? 1) indeed evaluates to #t (same
for Dylan, I guess).

SDS is written in MCL, and it includes a lightweight HTTP server that may
still be of interest to people.  It's designed to present a programming
abstraction of interacting with Lisp objects rather than "pages" and
"cgi-scripts."  This lets you do some fairly wizzy things in very small
amounts of code.  An old (1999) version of the server code can be found at
http://alvin.jpl.nasa.gov/gat/ftp/http.lsp.  (This version runs in CLisp.)

  It does not.

| (e.g. how should division of the elements of a matrix of integers through an
| integer behave?).

  Look, learn the language first, /then/ construct hypothetical problems.  If
  you want a division of two integers to yield an integer always, you have the
  four subtly different operators that does precisely this.  Using the general
  division operator is Just Plain Wrong.  Quit whining about non-problems.

| In addition and expression that evaluates to a float in one implementation
| might return a rational in another, which could lead to compatibility
| problems.

  Do you have any examples of this?

| I don't know what other things somebody might come up with, but I guess you
| get the idea.

  I see that you are happy constructing hypothetical problems, but you have so
  far not provided the connection from them to reality.  This is actually far
  more relevant than anything you can come up with in a vacuum.

| I'd be interested to know what the rationale for these decisions was.

  I believe this is part of the public record.  I have not checked this part
  of the specifications sufficiently closely, and even misremembered the issue
  on complex, but I believe the story on complex numbers have been covered
  sufficiently well in CLtL1 and CLtL2.

--
Erik Naggum, Oslo, Norway

I'd write something like do-combinations as a generator in python:

def combinations(k, objs):
    "Iterate recursively over the objects"
    if k > len(objs) or k == 0:
        return
    elif k == 1:
        for o in objs:
            yield [o]
    else:
        items = range(k); items[0] = objs[0]
        for items[1:] in combinations(k-1, objs[1:]):
            yield items
        for items in combinations(k, objs[1:]):
            yield items

for a, b, c in combinations(3, [1, 2, 3, 4, 5]):
    print "Combination is: ", a, b, c

Sure, I should probably use a more clever algorithm that doesn't eat
quite as much stack space, but that's easily done with a bit more
effort.  The important part is that I never have to cons up a list of
all the combinations.

The do-combinations example just happens to fit within the class of
macro-like problems that are solvable with generators.  I'm not trying
to argue that Python has anything like the expressive power of the CL
macro system, just that this particular example is doable.

There is a gaping lack of abstraction here; the user knows that combs
generates the combinations in a certain form and then pattern matches
on it to do the destructuring.

What int/int is mostly symptomatic of, I think, isn't exactly
either static typing or efficiency obsession. I think it's
symptomatic of a desire to be close to the machine, which
isn't quite the same as either. (BCPL was close to the machine
but not exactly statically typed; Haskell is statically typed
but not close to the machine. Java is close to the machine
but not efficient; Common Lisp is efficient but not close to
the machine.)

It's sort of true that if you're doing static types then
you need to consider types to be disjoint, in that you
need to know *the* type of every expression in the program,
but that's perfectly compatible with having subtype relations
too. Integer can be a subtype of Rational even if everything
gets typed either as Integer or as Ratio.

Of course, (truncate (/ x y)) feels inefficient. But it doesn't
take a specially smart compiler to make that feeling an illusion.

I'm not sure why this is so hard to understand.

<real> is the superclass of <float> and <rational>.

<float> is the superclass of <single-float> and <double-float>

<rational> is the superclass of <integer>

  One of the major problems I have with strong typing is precisely that it
  flies in the face of another pretentious theory, object-orientation, which
  supposedly should have a type hierarchy and run-time dispatch on the type of
  the actual object.  The two theories seem to be seriously at odds.  What we
  have in Common Lisp is thoroughly object-oriented approach.  This should be
  good, but somehow the strongly-typed nutjobs go "eep, eep" (thanks, Tim) and
  seem to ignore that their theories are all bunk if they cannot handle a type
  hierarchy.  Even before I started programming in Common Lisp, I found the
  desire to know /the/ (single) type of every expression to be suspect and the
  theories wanting when they made that premise.  As if you could not reason
  about types unless you had only one type!  As if you could not operate with
  union types created on the fly!  All bunk, I say.

| Of course, (truncate (/ x y)) feels inefficient. But it doesn't take a
| specially smart compiler to make that feeling an illusion.

  Not so.  Please remember the secondary return value.

--
Erik Naggum, Oslo, Norway

  Marvellous.

| If some quantity is specified in 100ths of a cent or 16ths of a cent then
| you use *that* as your unit.

  And if you multiply them, you get 1600th of a cent as the unit, then convert
  to another currency with 6-digit precision and you effectively compute with
  1,600,000,000th of a cent as the smallest unit.  Suddenly, you have only 22
  bits left for the cent value, and a transaction worth more than USD 42,000
  will no longer fit in your double-precision floating point number.  Great!

| I'm not sure why this is so hard to understand.

  Because, as several times in the past, you are just plain wrong, and you are
  the last person on the planet to admit it or figure it out.  So I shall do us
  all a huge favor and not attempt to convince you of the errors of your ways.

--
Erik Naggum, Oslo, Norway

Think about it in terms of dimensional analysis.  Physics uses values
with dimensions involving squared and higher powers of quantities.  
Accounting *doesn't*.

I worked in stockbroking and finance companies for a decade, writing
software dealing with stock and FX and government stock calculations.  I
never had any trouble meeting specs, using FP.

You're clearly outside your area of expertise here.

  I have worked with Oslo Stock Exchange and related businesses since 1990,
  when I specified the protocol between the exchange and brokers' computer
  systems. and I have designed and specified several protocol since then.  We
  had several problems with software vendors who used floating-point to store
  numeric values.  It was, even back then, a well-established fact that people
  ran into problems when they chose to use floating-point for numeric values
  that were not, in fact, floating point, but fix-point.

| You're clearly outside your area of expertise here.

  Your competence in assessing mine is also remarkably lacking.  That you keep
  on fighting is even more puzzling.  I think you should try to talk to someone
  who still cares about you about your incessant desire to make a fool of huge
  yourself when you are simply /factually/ wrong about something.

  How do you know that you have been meeting specs with floating point?  I
  think you are the kind of programmer who makes things work.  I am the kind
  of programmer who makes sure things do not fail.  What "works" for you is
  not even relevant to me.  There are sufficient problems with floating-point
  that it cannot be used in software that has to be exactly right all the time.
   It does not matter that you can detect when you are no longer exact, because
   you have to do something when that happens to become exact, again.  You
  could give up when you run out of precision in your floating-point format,
  but that is generally not an acceptable option.  So you have to a Plan B
  when this happens.  There may be good reasons to work with a Plan A and a
  Plan B, but during my long carreer as a programmer, I have seen one thing
  again and again that makes me desire not to rely on Plan B: It is almost
  never debugged properly because it is not expected to be used.  This is in
  sharp contrast to military-style contingency planning, where you rely on
  your contingency plan to be failsafe when your primary plan may fail.  I am
  not a fully trained paranoid (i.e., lawyer), but I believe that understanding
  the need for and nature of contingency planning is a requirement for anyone
  who teaches planning, and that is, in effect, what programmers teach their
  computers.

  By the way, if you want 53-bit integers with double-precision floating-point,
  why not go for the full 64-bit integers that you get even on 32-bit machines
  with C99's new `long long int´ type?  Or you could use the 80-bit floating-
  point that is used in the Intel Architecture.  Or perhaps the MMX registers.
  However, I would expect an implementation of a bignum library to make the
  most of the hardware.  If the implementation is not strong on bignus, that
  is, somewhat ironically, because bignums are also Plan B for most systems.

--
Erik Naggum, Oslo, Norway

  Units, dude.  Units.  Just /add/ two numbers with different denominators,
  and you get into this problem right away.  Granted, you can make do with
  400th of a cent, but then you need to get into the whole least common
  denominator game, and you should have used rationals to begin with.

--
Erik Naggum, Oslo, Norway

In my experience there are only two mathematical operations that one ever
actually performs on monetary values: multiplying a monetary value by a
scalar, or adding two monetary values with the same units.  But my
financial experience is pretty much limited to balancing my checkbook so
maybe I'm missing something here.

  I conclude that you are illiterate.  Go take a remedial reading class and
  when you have passed it, try to understand the very /next/ sentence from the
  article you obviously stopped comprehending after the first few words and
  thought you had understood enough to form your stupid response.  You will
  have to fax me the graduation papers before I believe you can read and I want
  to respond to you again.

--
Erik Naggum, Oslo, Norway

One could probably try to do that in a static language, too:
Always use the most ``arbitrary'' number type available at first,
and restrict when needed for efficiency.  But... does anybody
ever do that?  All static languages I've met so far distinguish
for instance between fixnums and bignums.  And all library
functions take fixnums.  Take any static language of your choice
and try to add 42 to a bignum.  It will be awkward: You'll first
have to convert 42 to a bignum.  And if you call a library
function that takes a fixnum you'll have to explicitly convert
back every bignum argument to a fixnum, handling all kinds of
exceptions along the way.  And that is not enough: We might have
to take rationals into account, so we can do something like

CL-USER 1 > (defparameter *a* 5)
*A*

CL-USER 2 > *a*
5

CL-USER 3 > (/ *a* 3)
5/3

CL-USER 4 > (setq *a* (/ *a* 3))
5/3

CL-USER 5 > (setq *a* (* 3 *a*))
5

So, we should have calculated with rationals, and only rationals,
to begin with.  So, now, our whole program has to deal with
rationals and not with integers (otherwise we'd quickly go nuts
being forced to convert fixnums, bignums and rationals into each
other).  This means, I now have to rewrite all of my software to
compute not only with bignums but with rationals.  God beware if
only a single float shows up somewhere...

Of course, all ``correctness'' is gone anyway, now: Every number,
even 0, is an arbitrary precision rational now; I only have to
``cast'' whenever I want to call a library function -- what can
the type checker possibly catch?  And this is different from Lisp:
When I know the argument of the function FOO will always be a
fixnum and I want more efficiency, I'll declare the argument to
be a fixnum within the definition of FOO and be done with it; but
in a static language, I'd have to change /every call/ to FOO so
it casts the argument to a fixnum.

Of course, along the way, you'll forget about 37 calls to FOO,
and the type checker will stop you for every single one of them.
And when you're done with all 37 error messages, and have added
all your 37 casts, you'll think: ``Thank God for my type checker.
He just saved me the time for finding 37 bugs.''

Or maybe not?

Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.

I completely agree that lots of financial arithmetic can be accurately
done in FP- but the potential for unexpected rounding is always there,
and when it shows up, you're screwed because you can't trust the
results of your arithmetic.  The likely result is lots of verification
of each step which is tricky because sometimes the rounding errors of
the original equation are compensated for by different rounding errors
in the verification, leading to your verification routines accepting
the wrong results.

One point you are missing with your talk about Plan B's and bignums is
that financial systems have specifications for their outputs as well as
their inputs.  It is no use using bignums internally if you then have to
feed the result into e.g. a stock exchange or Reuters/Bloomburg/whatever
system that is specified with a fixed number of significant figures.

  If you believe this is relevant, you assume too much.  Quit being so annoying.

--
Erik Naggum, Oslo, Norway

Or were you just deliberately not getting it?

marc

Using bignums and/or rationals internally that provide 'total
precision,' and well-trustable math predicates, means that you can be
quite certain that the _internal_ dealings with the values has been
handled faithfully.

If you then have to round it to three decimal places, for output
purposes, _that's fine_.

At the end of the day, what is likely to happen is that you'll have
sets of transactions that will be denominated in terms of having two
or three decimal places.  

Get them right and you've got the Important Thing right.  If using
bignums and rationals makes it easier to be confident that the values
are correct, then you've made life easier by using bignums/rationals.

And at the end of the day, the ultimate transactions will involve
things like:

  "Foo Paid $750.376 for 72.378 units of Bar."