1. Request: Integer Division
- Posted by SnakeCharmer Jan 02, 2013
- 1467 views
I offer to include integer division, for example:
integer Y = 3 integer Z = 2 integer X = Y \ Z
instead of
integer X = trunc(X/Z)
because it is more effective. First option is equivalent for
integer X = 0 while Y >= Z do X += 1 Y -= Z end while
Second option is equivalent for
integer Y = 3 integer Z = 2 atom YY = Y atom ZZ = Z atom XX = YY / ZZ integer X = trunc(XX)
As far as I know, integer addition and subtraction is much more effective than the division of floating point numbers.
2. Re: Request: Integer Division
- Posted by jimcbrown (admin) Jan 02, 2013
- 1466 views
This really should be in a Request-for-Feature ticket, but...
I offer to include integer division, for example:
integer Y = 3 integer Z = 2 integer X = Y \ Z
instead of
integer X = trunc(X/Z)
because it is more effective. First option is equivalent for
integer X = 0 while Y >= Z do X += 1 Y -= Z end while
Second option is equivalent for
integer Y = 3 integer Z = 2 atom YY = Y atom ZZ = Z atom XX = YY / ZZ integer X = trunc(XX)
As far as I know, integer addition and subtraction is much more effective than the division of floating point numbers.
I think the syntax is the most contriversal part here.
Adding a new builtin or machine func, like so:
integer X = integer_division(Y,Z)
which is equivalent to
integer X = 0 while Y >= Z do X += 1 Y -= Z end while
but implemented using integer division at the assembler level is pretty easy to do, and it's certainly a lot faster and more efficient than using intdiv.
I think however, changing the syntax such that
integer X = Y \ Z
does integer division, may break backwards compatibility and could be confusing, considering the way that the current and older versions of Euphoria handled this.
3. Re: Request: Integer Division
- Posted by useless_ Jan 02, 2013
- 1408 views
This really should be in a Request-for-Feature ticket, but...
It's funny how the unintuitive system for requesting features isn't used. Where is it?
I think the syntax is the most contriversal part here.
Maybe you meant "controversial", which is pronounced like it is spelled. If you are mispronouncing it, and then phonetically spelling it out, maybe you get "contriversal", but you might get "butterfly" too. I once watched and listened to a local human in the library try to look up "butterfly" by using phonetics, after 5 minutes she said out loud that maybe the 'b' was supposed to be silent, and spelled it out "atrfli", and began looking it up in the card catalog under 'a'.
integer X = integer_division(Y,Z)
I see no gain there. You are doing more typing, remembering a new keyword, spending more of your time, and possibly taking more cpu time to set up and execute.
useless
4. Re: Request: Integer Division
- Posted by jimcbrown (admin) Jan 02, 2013
- 1408 views
This really should be in a Request-for-Feature ticket, but...
It's funny how the unintuitive system for requesting features isn't used. Where is it?
I think the syntax is the most contriversal part here.
Maybe you meant "controversial",
I did.
which is pronounced like it is spelled. If you are mispronouncing it, and then phonetically spelling it out, maybe you get "contriversal", but you might get "butterfly" too. I once watched and listened to a local human in the library try to look up "butterfly" by using phonetics, after 5 minutes she said out loud that maybe the 'b' was supposed to be silent, and spelled it out "atrfli", and began looking it up in the card catalog under 'a'.
Nope. It was just a simple typo. (Unlike a similar example in one of your recent posts, http://openeuphoria.org/forum/m/120272.wc - which I consider hypocritical considering your reaction in http://openeuphoria.org/forum/m/117914.wc )
integer X = integer_division(Y,Z)
I see no gain there. You are doing more typing, remembering a new keyword, spending more of your time, and possibly taking more cpu time to set up and execute.
The point of adding a new integer_division() would be to take less cpu time to set up and execute (as compared to the existing intdiv() in std/math.e which is slower as it involves conversion to and operations with floating point numbers).
I wanted to just use the name intdiv() (since that's less typing than integer_division) which saves human time too - but that was already taken. I'm open to alternatives, though. idiv() perhaps?
5. Re: Request: Integer Division
- Posted by mattlewis (admin) Jan 02, 2013
- 1402 views
I wanted to just use the name intdiv() (since that's less typing than integer_division) which saves human time too - but that was already taken. I'm open to alternatives, though. idiv() perhaps?
It seems like we'd update the existing function to use whatever new implementation we came up with. If we're adding an operator, then the function would presumably become deprecated. If a machine func, then it would be the "official" wrapper for the machine func call.
I don't think I'd worry too much about backwards compatibility in the case of adding the operator, which I suspect would be the right way to go, since we'd presumably also add =\ as an operator and the performance and readability improvements those operators provide.
Matt
6. Re: Request: Integer Division
- Posted by jimcbrown (admin) Jan 02, 2013
- 1394 views
I wanted to just use the name intdiv() (since that's less typing than integer_division) which saves human time too - but that was already taken. I'm open to alternatives, though. idiv() perhaps?
It seems like we'd update the existing function to use whatever new implementation we came up with. If we're adding an operator, then the function would presumably become deprecated. If a machine func, then it would be the "official" wrapper for the machine func call.
I don't think I'd worry too much about backwards compatibility in the case of adding the operator, which I suspect would be the right way to go, since we'd presumably also add =\ as an operator and the performance and readability improvements those operators provide.
Matt
Ah, I didn't think about using the backslash as the low-level fast intdiv operator. I think this is the best approach.
7. Re: Request: Integer Division
- Posted by mattlewis (admin) Jan 02, 2013
- 1382 views
Ah, I didn't think about using the backslash as the low-level fast intdiv operator. I think this is the best approach.
Gah! That was SnakeCharmer's original proposal:
I offer to include integer division, for example:
integer Y = 3 integer Z = 2 integer X = Y \ Z
instead of
integer X = trunc(X/Z)
Matt
8. Re: Request: Integer Division
- Posted by jimcbrown (admin) Jan 02, 2013
- 1398 views
Ah, I didn't think about using the backslash as the low-level fast intdiv operator. I think this is the best approach.
Gah! That was SnakeCharmer's original proposal:
I offer to include integer division, for example:
integer Y = 3 integer Z = 2 integer X = Y \ Z
instead of
integer X = trunc(X/Z)
Matt
Doh! I read that as the forward slash.
9. Re: Request: Integer Division
- Posted by useless_ Jan 02, 2013
- 1386 views
integer X = integer_division(Y,Z)
I see no gain there. You are doing more typing, remembering a new keyword, spending more of your time, and possibly taking more cpu time to set up and execute.
The point of adding a new integer_division() would be to take less cpu time to set up and execute (as compared to the existing intdiv() in std/math.e which is slower as it involves conversion to and operations with floating point numbers).
So Eu tracks the declared type integer all thru the program, and then ignores it and converts to type atom (floating point), does the most costly math possible on it, then truncates it and re-typecasts it as integer?
Then i'd call this ticket (i mean Request for Feature?) a bug fix request.
My objection was based on hearing many years ago that Intel cpus got rid of the integer math unit and essentially ran the math halfway thru the float pipeline anyhow.
useless
10. Re: Request: Integer Division
- Posted by CoJaBo2 Jan 02, 2013
- 1401 views
This really should be in a Request-for-Feature ticket, but...
It's funny how the unintuitive system for requesting features isn't used. Where is it?
Ah yes, i'll remember that. And alias "ticket" as a "Request for Feature". </sarcasm>
Its a pretty standard term http://en.wikipedia.org/wiki/Ticket
Nope. It was just a simple typo. (Unlike a similar example in one of your recent posts, http://openeuphoria.org/forum/m/120272.wc - which I consider hypocritical considering your reaction in http://openeuphoria.org/forum/m/117914.wc )
Oh come on, it wasn't that simple, there were several mistakes in the one word. You know i don't bother looking at those links? I can't imagine the time you put into indexing and referencing my words.
useless
You complain on almost every thread here that "everyone is picking a fight with you". How, exactly, is this not you picking a fight with everyone else?
Note that this thread is about adding an operator for integer division. It is not about the meaning of the word "ticket". It is not about the spelling of the word "controversial". It is not a historical survey of every past flamewar on this forum.
This kind of nonsense, that unfailingly pops up on every single thread, is undoubtedly driving away newcomers, who ask a simple question only to see that 90% of the thread becomes an argument on whether it KB means kilobits or was a typo for megabits or something equally pointless.
Can we drop this now? IMVHO, the mods should start simply deleting all off-topic posts (like this one) instead of replying to them and dragging the thread further and further off topic.
11. Re: Request: Integer Division
- Posted by jimcbrown (admin) Jan 02, 2013
- 1385 views
integer X = integer_division(Y,Z)
I see no gain there. You are doing more typing, remembering a new keyword, spending more of your time, and possibly taking more cpu time to set up and execute.
The point of adding a new integer_division() would be to take less cpu time to set up and execute (as compared to the existing intdiv() in std/math.e which is slower as it involves conversion to and operations with floating point numbers).
So Eu tracks the declared type integer all thru the program, and then ignores it and converts to type atom (floating point), does the most costly math possible on it, then truncates it and re-typecasts it as integer?
That was my understanding of how things worked today - except if you forget the call to trunc() then you get an ex.err-style crash instead (since atoms with fractions can't be assigned to integers).
My objection was based on hearing many years ago that Intel cpus got rid of the integer math unit and essentially ran the math halfway thru the float pipeline anyhow.
Hmm... well, that's still faster than how Euphoria does it now, though.
Then i'd call this ticket (i mean Request for Feature?) a bug fix request.
Well, no actual functionality is incorrect - it's just slower in a well understood way and requires more steps.
12. Re: Request: Integer Division
- Posted by mattlewis (admin) Jan 02, 2013
- 1371 views
So Eu tracks the declared type integer all thru the program, and then ignores it and converts to type atom (floating point), does the most costly math possible on it, then truncates it and re-typecasts it as integer?
Actually, there are (and have been for as long as I'm aware) 4 division opcodes:
- DIVIDE
- DIV2
- FLOOR_DIV
- FLOOR_DIV2
The DIV2 versions attempt to use bitwise optimizations. The FLOOR versions use C integer division if the divisor and dividend are euphoria integer values (we may not know until runtime). One potential difference with explicit integer division is how we would deal with fractional values.
I can think of two ways to deal with this:
- floor( a / b )
- floor( floor(a) / floor(b) )
The second option would be similar to what you'd get in, say, C, where you'd do casts to int instead of calling floor() in order to invoke integer division on FP values.
Matt
13. Re: Request: Integer Division
- Posted by useless_ Jan 02, 2013
- 1342 views
The FLOOR versions use C integer division if the divisor and dividend are euphoria integer values (we may not know until runtime)
If we may not know, then for general knowledge, what advantage is there in declaring
integer varname
at the top of the code, instead of atom or object? I have tended to use integers in loops where speed was important, thinking they were overall faster to compute.
useless
14. Re: Request: Integer Division
- Posted by mattlewis (admin) Jan 02, 2013
- 1358 views
The FLOOR versions use C integer division if the divisor and dividend are euphoria integer values (we may not know until runtime)
If we may not know, then for general knowledge, what advantage is there in declaring
integer varname
at the top of the code, instead of atom or object? I have tended to use integers in loops where speed was important, thinking they were overall faster to compute.
If you declare something to be an integer, then we do know. But you may instead be using an atom. Or a value stored in a sequence, or the return value from a function. Or a sequence full of...well, who knows?
In general, declaring things that you know will always be integers to be integers does offer speed benefits, and I do this as much as possible, too. There is a lot of stuff in both the interpreter and translator to optimize this sort of thing. However, other cases where we can't determine the storage type at parse / compile time have to be dealt with, too.
Matt
15. Re: Request: Integer Division
- Posted by jaygade Jan 02, 2013
- 1324 views
I'm confused -- I thought that Euphoria already did integer division on integers, assuming all variables in the expression are integers (not counting literals).
Is that not the case? Regardless of a new feature or not, is that mentioned in the manual?
16. Re: Request: Integer Division
- Posted by jimcbrown (admin) Jan 03, 2013
- 1317 views
I'm confused -- I thought that Euphoria already did integer division on integers, assuming all variables in the expression are integers (not counting literals).
Is that not the case?
No. Try out the following code:
integer x, y, z y = 1 z = 2 x = y/z ? x
Regardless of a new feature or not, is that mentioned in the manual?
I'm not sure if this is explicitly mentioned anywhere, but it has been this way since Euphoria 1.5 (if not earlier).
17. Re: Request: Integer Division
- Posted by EUWX Jan 03, 2013
- 1202 views
Would it not be a simple matter to have a defined function?
public function integer_divide(integer x, integer y, decimal=0)
18. Re: Request: Integer Division
- Posted by jaygade Jan 03, 2013
- 1239 views
Ah, fair enough.
I'm neither in favor nor opposed to further increasing Euphoria's complexity by introducing a new operator.
Since I come from the old-school BASICs, I never had much problem with typing in
100 x = int(y/z)
Or the Euphoria equivalent. I can only say that explicitly specifying a function makes it clear to the interpreter and the reader that the intent is to do integer division. In that respect, it is preferable to the way that other languages handle this case.
19. Re: Request: Integer Division
- Posted by DerekParnell (admin) Jan 04, 2013
- 1249 views
Ah, fair enough.
I'm neither in favor nor opposed to further increasing Euphoria's complexity by introducing a new operator.
Since I come from the old-school BASICs, I never had much problem with typing in
100 x = int(y/z)
Or the Euphoria equivalent. I can only say that explicitly specifying a function makes it clear to the interpreter and the reader that the intent is to do integer division. In that respect, it is preferable to the way that other languages handle this case.
Have you ever coded in COBOL?
DIVIDE y BY z WITH ROUNDING GIVING x.No function calls and no operators
20. Re: Request: Integer Division
- Posted by jaygade Jan 04, 2013
- 1248 views
Have you ever coded in COBOL?
DIVIDE y BY z WITH ROUNDING GIVING x.No function calls and no operators
Heh, no, but I remember seeing it in my Dad's college textbooks.
The nightmares didn't last more than a couple of nights.