Hello all:
I've decided I'm going to try to merge in stuff from my QTILITY library [1] in an attempt to reduce the number of utility libraries out there -- provided the stuff fits with the goals of Alexandria. Xach and I decided it's best not to add more utility libraries to Quicklisp.
I've created a patch that adds MULF and DIVF, which do what you might expect (modify macros for * and /). I also added some numerical predicates that I myself like, as well as others: POSITIVEP, NEGATIVEP, NON-POSITIVE-P, NON-NEGATIVE-P, NON-ZERO-P. As you might notice, they sound especially familiar to those who read mathematics literature.
Also, would it be possible for me to have push permissions?
I hope you'll take these attached patches into consideration.
Thanks,
Robert Smith
Hi Robert,
Robert Smith quad@symbo1ics.com writes:
I've created a patch that adds MULF and DIVF, which do what you might expect (modify macros for * and /). I also added some numerical predicates that I myself like, as well as others: POSITIVEP, NEGATIVEP, NON-POSITIVE-P, NON-NEGATIVE-P, NON-ZERO-P. As you might notice, they sound especially familiar to those who read mathematics literature.
MULF and DIVF could be useful (but note that many people spell the first as MULTF). However, I don't think that MUL(T)F and DIVF should take a default factor/divisor argument --- personally, I would find (DIVF FORM) somewhat confusing.
I don't really see the value of aliases for PLUSP and MINUSP, and I have some doubts about NON-ZERO-P too.
Best,
Tamas
On Wed, Apr 25, 2012 at 12:30 AM, Tamas K Papp tkpapp@gmail.com wrote:
MULF and DIVF could be useful (but note that many people spell the first as MULTF). However, I don't think that MUL(T)F and DIVF should take a default factor/divisor argument --- personally, I would find (DIVF FORM) somewhat confusing.
I agree with not having default arguments, now that you say it. I think my original intention was to be more consistent with INCF and DECF, but "inc" and "dec" both implicitly imply "increment/decrement", which in turn imply by 1.
I don't really see the value of aliases for PLUSP and MINUSP, and I have some doubts about NON-ZERO-P too.
Not unreasonable.
All of these show up in a lot of mathematical code I (and coworkers) write. I only argue for POSITIVEP, etc., because that is an extremely common term. If we need to make it more substantial than just aliasing PLUSP, then we can let POSITIVEP also return T for +0.0, similarly for NEGATIVEP and -0.0. I don't really like that, but at least it has utility.
As for doubts about NON-ZERO-P: yes, it can of course be written (NOT (ZEROP N)), as the definition says, but I don't think anyone has really disagreed with the Lisp standard having CL:1+, which in many implementations is transformed to (LAMBDA (N) (+ 1 N)).
Having its own function is also useful for functional operations, like filtering. Real-world example: finding non-zero values in the diagonal of one of the matrices in a singular value decomposition and finding those indexes in the other factor lets us find the basis of the kernel/null space of the matrix.
Quite simply, I'd say, the concept of non-zeroness as an almost atomic notion is pervasive in especially mathematics, which Lisp happens to be good at.
Thanks for the comments.
Robert Smith
Hi Robert,
Robert Smith quad@symbo1ics.com writes:
On Wed, Apr 25, 2012 at 12:30 AM, Tamas K Papp tkpapp@gmail.com wrote:
I don't really see the value of aliases for PLUSP and MINUSP, and I have some doubts about NON-ZERO-P too.
Not unreasonable.
All of these show up in a lot of mathematical code I (and coworkers) write. I only argue for POSITIVEP, etc., because that is an extremely common term. If we need to make it more substantial than just aliasing PLUSP, then we can let POSITIVEP also return T for +0.0, similarly for NEGATIVEP and -0.0. I don't really like that, but at least it has utility.
CL already has FLOAT-SIGN.
Having its own function is also useful for functional operations, like filtering. Real-world example: finding non-zero values in the diagonal of one of the matrices in a singular value decomposition and finding those indexes in the other factor lets us find the basis of the kernel/null space of the matrix.
First, I would never want test for something being (non)zero in those cases (because of numerical error). I would test with something like
(let ((tolerance (expt epsilon (/ n)))) (lambda (x) (<= (abs x) tolerance)))
where epsilon corresponds to the float type, and n is 2 or 3, depending on the application. This is what is usually done in code that calculates rank numerically.
Second, if you need a function, you can use (COMPLEMENT #'ZEROP).
Quite simply, I'd say, the concept of non-zeroness as an almost atomic notion is pervasive in especially mathematics, which Lisp happens to be good at.
Sure, but you have to be careful when mapping abstract concepts to floating point calculations.
Best,
Tamas
On 25 April 2012 06:03, Robert Smith quad@symbo1ics.com wrote:
I've created a patch that adds MULF and DIVF, which do what you might expect (modify macros for * and /). I also added some numerical predicates that I myself like, as well as others: POSITIVEP, NEGATIVEP, NON-POSITIVE-P, NON-NEGATIVE-P, NON-ZERO-P. As you might notice, they sound especially familiar to those who read mathematics literature.
(Didn't check your code yet, this is just based on the names.)
DIVF and MULF I think I'm fine with.
Though I share most of Tamas' reservations re. POSITIVEP and NEGATIVEP, but acknowledge that they form a good symmetry with the NON-*-P versions -- so I think I'm fine with those going in as well. If they go in, they should be synonyms for PLUSP and MINUSP, though -- not subtly different.
As for NON-*-P ... I kind of like them. While COMPLEMENT works, I'm pretty glad we have REMOVE-IF-NOT, instead of being forced to write
(remove-if (complement #'foop) ...)
Similarly, I think (NON-NEGATIVE-P X) is cleaner to read than (NOT (MINUSP X)) -- though the cognitive cost difference it pretty trivial.
Thinking about them.
Also, would it be possible for me to have push permissions?
Not for the asking, no.
If you provide several high quality patches and display the kind of judgement we're looking for, yes, eventually.
Cheers,
-- Nikodemus
alexandria-devel@common-lisp.net
-
Nikodemus Siivola -
Robert Smith -
Tamas K Papp -
Tamas Papp