Division by Integer

Division by Integer

Anonymous
Not applicable
2,212 Views
8 Replies
Message 1 of 9

Division by Integer

Anonymous
Not applicable

Being a relative newcomer to lisp, I didn't know some of the basic flaws in the lisp language. I've just been writing a piece of code that needed the inverse of a number within it. Pretty simple I thought. But:

(/ 1 20)
Returns 0

 

However turn the number unnecessarily into a real number then it works just fine:

(/ 1 20.0)
or
(/ 1 (float 20))
Return 0.05

 

Undoubtedly experianced lispers all know this but it doesn't exactly jump off the page of the 'AutoLISP Functions By Name' site. In fact it says:

(/ [number number ...])

number 
Type: Integer or Real

 

Why doesn't division by integer  work in lisp? Why hasn't AutoDesk fixed this basic mathematical function that even an early 1970's LED calculator was capable of?

Are there any other daft shortcomings within lisp thst anybody knows of?

 

Rant over

0 Likes
2,213 Views
8 Replies
Replies (8)
Message 2 of 9

phanaem
Collaborator
Collaborator
It's not a bug or some weakness of AutoLisp. Sometimes, when you deal with integers only, it is of real use.
You just need to be aware of this and use the proper transformation when you need it. Either (/ 4 (float 5)) and (/ 4 1.0 5) works.

PS. Other Lisp variations uses 2 different functions to return an integer or a floating-point number: "/" and "div"
0 Likes
Message 3 of 9

ВeekeeCZ
Consultant
Consultant

 

(/ integer integer) = integer

 

if at least one of them is a real, then returns a real.

 

I just always use (/ a 20.) to make sure that integer does not surprise me... (if I am not sure if 'a' is an integer or real.

0 Likes
Message 4 of 9

Kent1Cooper
Consultant
Consultant

@Anonymous wrote:

.... 

Why doesn't division by integer  work in lisp? ....


Just so you know....  Division by integer does work and returns a non-integer result, if the first number argument is a real number.  The real number doesn't need to be the divisor [second (or subsequent) number argument] -- it can be any of the numbers involved.  It's only if all numbers involved are integers that it returns an integer result.

 

I agree that Help should be explicit about this.  The example with two integer arguments is something that divides equally, which doesn't make that clear.

Kent Cooper, AIA
Message 5 of 9

Anonymous
Not applicable

BeekeeCZ wrote:

'I just always use (/ a 20.)'

 

And Kent wrote:

'....if the first number argument is a real number'

 

But why should we need to? Imagine the fuss if Microsoft had coded Excel like that, or Casio their calclators !

 

'God grant me the serentity....'

0 Likes
Message 6 of 9

Kent1Cooper
Consultant
Consultant

@Anonymous wrote:

@ВeekeeCZ wrote:

'I just always use (/ a 20.)'

 

@Anonymous Kent wrote:

'....if the first number argument is a real number'

 

But why should we need to? ....


For myself, I don't think I would ever need the integer-only operation, either, but @phanaem may be able to answer that question with some enlightenment about a situation meeting their description in the first line in Post 2.

Kent Cooper, AIA
0 Likes
Message 7 of 9

dbroad
Mentor
Mentor

As with the others, I don't see the problem here.  That the division operator uses promotion rules to go from integer to real is pretty obvious in the user help file examples and the supplemental links about number handling are also helpful. See the 2016 help docs here.  Now compare that coverage with the 2011 help on the division function here.  This is a significant improvement.

 

Help files are not designed to substitute for either textbooks, classes, or programming experience.  Specify the domain for your arguments and test all functions for the specified domain until you are certain of what the return values will be.

Architect, Registered NC, VA, SC, & GA.
0 Likes
Message 8 of 9

phanaem
Collaborator
Collaborator

@Kent1Cooper wrote:

For myself, I don't think I would ever need the integer-only operation, either, but @phanaem may be able to answer that question with some enlightenment about a situation meeting their description in the first line in Post 2.


Yes, I have some example, but it has nothing to do with the AutoCAD, is pure mathematic.

Some time ago I've made an entire set of operations for big numbers. I mean really big integers..

2^200

_$ (expo '(2) 200)

(1 6 0 6 9 3 8 0 4 4 2 5 8 9 9 0 2 7 5 5 4 1 9 6 2 0 9 2 3 4 1 1 6 2 6 0 2 5 2 2 2 0 2 9 9 3 7 8 2 7 9 2 8 3 5 3 0 1 3 7 6)

 

A comparison between integer and real numbers:

_$ (expo '(2) 3)
(8)
_$ (expo '(2.0) 3)
(0.16 1.6 8.0)

I guess I could acomplish the same result with a little extra work, but integers' division behavior helps alot.

0 Likes
Message 9 of 9

martti.halminen
Collaborator
Collaborator

 

You've hit one of the historical oddities in Lisp, from long before Autodesk got mixed in it.

 

The cultural idea here is that you don't get automatic floating-point contagion, you have to ask for it. If you are doing serious integer mathematics with exact numbers, you really don't want the system to change to floating point in the middle of a calculation.

 

- In Common Lisp you also have rational numbers, so there the integer division won't truncate, it just returns a ratio.

 

http://www.lispworks.com/documentation/HyperSpec/Body/f_sl.htm, and alternatives: http://www.lispworks.com/documentation/HyperSpec/Body/f_floorc.htm#floor

 

 

In addition to the general oddities of the Lisp language family, you also need to beware some of the things AutoLISP does differently than other Lisps.

 

For example:

 

Autolisp:
_$ (< nil 5)
T

 

 

Lispworks:

 

CL-USER 5 > (< nil 5)

Arithmetic error in < of (NIL 5): Arguments must be real numbers.
[Condition of type CONDITIONS::ARITHMETIC-TYPE-ERROR-WITH-MESSAGE]

 

--