Yes, Python3 did switch from 1/2 returning a float, but Python3 still is having major problems with acceptance from the Python community, so I don't think that's the best example to use. It is a bit of a mess when you look at a number of languages.
Python2 Python3 Lua Julia CC++ CacheObjectScript I*I I I I I I D I/I I F F F I D I//I I I I R - - I\div<tab>I - - - I - - where: I = Integer, F = Binary Float, D = Decimal Float, R = Rational, - = syntax error On Sunday, April 3, 2016 at 8:01:07 AM UTC-4, Stefan Karpinski wrote: > Python 3 changed the meaning of 1/2 to be 0.5, so arguing from a Pythonic > perspective would seem to indicate that Julia has avoided Python's original > mistake for / and chosen a behavior that Guido van Rossum and the the > Python community at large consider to be sufficiently much better to > warrant a rather long and annoying deprecation process. Also note that C > and Python are inconsistent in what / means: in C it does truncated > division while in Python it does floored division. Neither choice is > obviously entirely better, which is itself a problem: so you want / to be > integer division? Which one? > > On Sat, Apr 2, 2016 at 4:18 PM, Matt Bauman <[email protected] > <javascript:>> wrote: > >> I don't want to get too deep into the weeds here, but I want to point out >> some things I like about Julia's closed ranges: >> >> * Julia's ranges are just vectors of indices. In exchange for giving up >> Python's offset style slicing, you get a fully-functional mathematical >> vector that supports all sorts of arithmetic. Idioms like `(-1:1)+i` allow >> you to very easily slide a 3-element window along your array. >> >> * Since they represent a collection of indices instead of elements >> between two fenceposts, Julia's ranges will throw bounds errors if the >> endpoints go beyond the end of the array. I find these sorts of errors >> extremely valuable — if I'm indexing with a N-element range I want N >> elements back. >> >> * The only thing that's special about indexing by ranges is that they >> compute their elements on-the-fly and very efficiently. You can create >> your own range-like array type very easily, and it can even generalize to >> multiple dimensions quite nicely. >> >> * Being vectors themselves, you can index into range objects. In fact, >> they will smartly re-compute new ranges upon indexing (if they can). >> >> * In exchange for Python's negative indexing, you get the `end` keyword. >> It can be used directly in all sorts of computations. In fact, you could >> use it in your example, replacing the hard-coded 100 with `end`. Now it >> supports arrays of all lengths. Circular buffers can be expressed as >> `buf[mod1(i, >> end)]`. >> >> Of course there are trade-offs to either approach, and it takes time to >> adjust when moving from one system to the other. >> >> If you work a lot with images and other higher-dimensional arrays, I >> recommend taking a look at Julia's multidimensional algorithms. I think >> Julia has a lot to offer in this domain and is quite unique in its >> multidimensional support. http://julialang.org/blog/2016/02/iteration >> >> >> On Saturday, April 2, 2016 at 7:55:55 AM UTC-4, Spiritus Pap wrote: >>> >>> Hi there, >>> >>> TL;DR: A lot of people that could use julia (researchers currently using >>> python) won't. I give an example of how it makes my life hard, and I try to >>> suggest solutions. >>> >>> Iv'e been introduced to julia about a month ago. >>> I'm an algorithmic researcher, I write mostly research code: statistics, >>> image processing, algorithms, etc. >>> I use mostly python with numpy for my stuff, and C/++ when I need >>> performance. >>> I was really happy when I heard of julia, because it takes the >>> simplicity of python and combines it with JIT compilation for speed! >>> >>> I REALLY tried to use julia, I really did. I tried to convince my >>> friends at work to use it too. >>> However, there are a few things that make it unusable the way it is. >>> >>> Decisions that in my opinion were made by people who do not write >>> research-code: >>> 1. Indexing in Julia. being 1 based and inclusive, instead of 0 based >>> and not including the end (like in c/python/lots of other stuff) >>> 2. No simple integer-division operator. >>> >>> A simple example why it makes my *life hard*: Assume there is an array >>> of size 100, and i want to take the i_th portion of it out of n. This is a >>> common scenario for research-code, at least for me and my friends. >>> In python: >>> a[i*100/n:(i+1)*100/n] >>> In julia: >>> a[1+div(i*100,n):div((i+1)*100,n)] >>> >>> A lot more cumbersome in julia, and it is annoying and unattractive. >>> This is just a simple example. >>> >>> *Possible solutions:* >>> The reason I'm writing this post is because I want to use julia, and I >>> want to to become great. >>> *About the division:* I would suggest *adding *an integer division >>> *operator*, such as *//*. Would help a lot. Yes, I think it should be >>> by default, so that newcomers would need the least amount of effort to use >>> julia comfortably. >>> >>> *About the indexing:* I realize that this is a decision made a long >>> time ago, and everything is built this way. Yes, it is like matlab, and no, >>> it is not a good thing. >>> I am a mathematician, and I almost always index my sequences expressions >>> in 0, it usually just makes more sense. >>> The problem is both in array (e.g. a[0]) and in slice (e.g. 0:10). >>> An array could be solved perhaps by a *custom *0 based *array object*. >>> But the slice? Maybe adding a 0 based *slice operator*(such as .. or >>> _)? is it possible to do so in a library? >>> >>> I'd be happy to write these myself, but I believe these need to be in >>> the standard library. Again, so that newcomers would need the least amount >>> of effort to use julia comfortably. >>> If you have better suggestions, I'd be happy to hear. >>> >>> Thank you for your time >>> >> >
