3 ms·

Lisp's numeric tower is, if anything, a great example of how not to do mathematics. It is just too coarse-grained to be useful: it lumps into a single giant str

Lisp's numeric tower is, if anything, a great example of how not to do mathematics. It is just too coarse-grained to be useful: it lumps into a single giant structure every possibly imaginable number. On that basis, you cannot easily constrain yourself to working on a more specific algebraic structure of interest. If you need a total order, you are screwed up: the numeric tower includes complex numbers. If you need to work on a quotient ring, you are screwed up: the numeric tower includes floats. Haskell's relatively fine-grained distinctions between numeric types is nothing like Lisp's numeric tower.

lispm 13y ago
> it lumps into a single giant structure every possibly imaginable number. What? There are several different numeric types. It's there to implement more advanced mathematics capabilities. Like in Axiom, which runs on top of Common Lisp. > Haskell's relatively fine-grained distinctions between numeric types is nothing like Lisp's numeric tower. Haskell's numeric capabilities were in part copied from Common Lisp.
- catnaroek 13y ago
  > What? There are several different numeric types. It's there to implement more advanced mathematics capabilities. There is no such thing as multiple types in Common Lisp. > Haskell's numeric capabilities were in part copied from Common Lisp. Haskell's standard type classes include the notions of ring (Num), field (Fractional* ) and integer (Integral). (Notably absent is the notion of semiring, which would be useful for a type of natural numbers, though.) The importance of making these distinctions is that you can statically ensure that you are using certain algebraic structures but not others. * Somehow floating points were invited to the party, but, hey! I guess no standard library can be perfect.
  - lispm 13y ago
    For most practical applications this is not necessary at all. Common Lisp has countless mathematical applications which make use of its various numeric data types.
    - catnaroek 13y ago
      We are using different notions of type. For me, a type is a static guarantee about the meaning of a syntactic term in the program, rather than a mere labelling of values during the runtine process. In the sense of type that I use, Common Lisp does not have but just one type, and it is not even a type of numbers - it is a type of everything. All in all, I did not intend to overly diss Common Lisp. It is a very flexible, expressive and powerful language. I am just saying that, at least from my point of view, Common Lisp does not look particularly inspired by mathematics.
JadeNB 13y ago
> Haskell's relatively fine-grained distinctions between numeric types is nothing like Lisp's numeric tower. Ugh; we're not calling out Haskell's numeric hierarchy as a good example, are we? (Well, maybe it's a good example of how to handle numbers—although I find the lack of a positive-integer type a pain—but it's certainly not a good example of how to handle general algebraic structures, which is what it seems to pretend to be. What in the world is `sign` doing in there, for example?)
- catnaroek 13y ago
  > Well, maybe it's a good example of how to handle numbers—although I find the lack of a positive-integer type a pain— In another subthread I mentioned the absence of a Semiring type class, which should be a superclass of Ring (Haskell's Num) and provide addition, multiplication and fromNatural. So, yeah, I am not entirely happy with Haskell's standard library either, but the situation in other (general-purpose) programming languages is even worse. > but it's certainly not a good example of how to handle general algebraic structures, which is what it seems to pretend to be. How so? The standard library may be flawed, but the core language is perfectly capable of handling general algebraic structures. The only legitimate point of pain I can see is that a type or tuple of types can only be an instance of a type class in at most one way, for which the solution (admittedly, rather ugly) is to use newtype. A non-ugly solution would be to use something like Standard ML's module system, but in no way it would improve the situation to move closer to Common Lisp.
  - JadeNB 13y ago
    > How so? The standard library may be flawed, but the core language is perfectly capable of handling general algebraic structures. I mean algebraic structures in the mathematical sense you mentioned (rings, groups, &c.), not in the computer-science sense of algebraic data types.
    - catnaroek 13y ago
      > I mean algebraic structures in the mathematical sense you mentioned (rings, groups, &c.) I know you meant those. And I meant those as well.

lispm 13y ago

> it lumps into a single giant structure every possibly imaginable number. What? There are several different numeric types. It's there to implement more advanced mathematics capabilities. Like in Axiom, which runs on top of Common Lisp. > Haskell's relatively fine-grained distinctions between numeric types is nothing like Lisp's numeric tower. Haskell's numeric capabilities were in part copied from Common Lisp.

catnaroek 13y ago
> What? There are several different numeric types. It's there to implement more advanced mathematics capabilities. There is no such thing as multiple types in Common Lisp. > Haskell's numeric capabilities were in part copied from Common Lisp. Haskell's standard type classes include the notions of ring (Num), field (Fractional* ) and integer (Integral). (Notably absent is the notion of semiring, which would be useful for a type of natural numbers, though.) The importance of making these distinctions is that you can statically ensure that you are using certain algebraic structures but not others. * Somehow floating points were invited to the party, but, hey! I guess no standard library can be perfect.
- lispm 13y ago
  For most practical applications this is not necessary at all. Common Lisp has countless mathematical applications which make use of its various numeric data types.
  - catnaroek 13y ago
    We are using different notions of type. For me, a type is a static guarantee about the meaning of a syntactic term in the program, rather than a mere labelling of values during the runtine process. In the sense of type that I use, Common Lisp does not have but just one type, and it is not even a type of numbers - it is a type of everything. All in all, I did not intend to overly diss Common Lisp. It is a very flexible, expressive and powerful language. I am just saying that, at least from my point of view, Common Lisp does not look particularly inspired by mathematics.

JadeNB 13y ago

> Haskell's relatively fine-grained distinctions between numeric types is nothing like Lisp's numeric tower. Ugh; we're not calling out Haskell's numeric hierarchy as a good example, are we? (Well, maybe it's a good example of how to handle numbers—although I find the lack of a positive-integer type a pain—but it's certainly not a good example of how to handle general algebraic structures, which is what it seems to pretend to be. What in the world is `sign` doing in there, for example?)

catnaroek 13y ago
> Well, maybe it's a good example of how to handle numbers—although I find the lack of a positive-integer type a pain— In another subthread I mentioned the absence of a Semiring type class, which should be a superclass of Ring (Haskell's Num) and provide addition, multiplication and fromNatural. So, yeah, I am not entirely happy with Haskell's standard library either, but the situation in other (general-purpose) programming languages is even worse. > but it's certainly not a good example of how to handle general algebraic structures, which is what it seems to pretend to be. How so? The standard library may be flawed, but the core language is perfectly capable of handling general algebraic structures. The only legitimate point of pain I can see is that a type or tuple of types can only be an instance of a type class in at most one way, for which the solution (admittedly, rather ugly) is to use newtype. A non-ugly solution would be to use something like Standard ML's module system, but in no way it would improve the situation to move closer to Common Lisp.
- JadeNB 13y ago
  > How so? The standard library may be flawed, but the core language is perfectly capable of handling general algebraic structures. I mean algebraic structures in the mathematical sense you mentioned (rings, groups, &c.), not in the computer-science sense of algebraic data types.
  - catnaroek 13y ago
    > I mean algebraic structures in the mathematical sense you mentioned (rings, groups, &c.) I know you meant those. And I meant those as well.