On Tue, Apr 5, 2016 at 8:27 AM, Scott Jones
wrote:
>
That chart shows that Julia is the *only* language that does not have a one
> or two *ASCII* character infix operator for integer division.
>
Never mind JavaScript, Perl, Matlab, R, PHP or Lisp. Nobody uses those.
The fact is that there's a
It may have been already proposed sometimes, for some other things (and
possibly by myself), but, what about a module that simple defines
*macro ~(x,y); div(x,y); end*
? Enabling code like *4~3*.
Would it be considered idiomatic enough to use such available option?
On Tue, Apr 5, 2016 at 9:19
On Tuesday, April 5, 2016 at 2:42:56 AM UTC-4, Tomas Lycken wrote:
>
> There are only 6 uses of // outside of rationals.jl in base (4 of those
> are in mpfr.jl), compared to 187 uses of div, and 22 uses of ÷. (that’s
> uses, not definitions, exports, documentation, although the ratios are very
lol,
thanks for the python 3 update! I need to get using that one of these days
...
Yeah I didn't see your comment as very critical, I just wanted to say we
can all coexist in general :)
I find the holy wars on basic stuff like this always a bit mind blowing.
Julia continually impresses me wit
Sweetness. Thanks for the clarification!
On Tuesday, April 5, 2016 at 7:42:02 AM UTC-7, Cristóvão Duarte Sousa wrote:
>
>
> For the julia example isn't matlab like concatenation using ';' being
>> removed from julia?
>>
>
> No. Just the concatenation using ','
> (AFAIK)
>
>
> For the julia example isn't matlab like concatenation using ';' being
> removed from julia?
>
No. Just the concatenation using ','
(AFAIK)
On Tuesday, April 5, 2016 at 3:36:09 PM UTC+2, Gabriel Gellner wrote:
>
> you can do the python example as:
>
> a[[1, 4] + range(7, 17, 2)]
> (ignoring the issues that this is not the same range as julia since python
> uses 0-based indices ...)
>
Thanks. I'm getting an error, though:
TypeError:
+ 1 to Gabriel's reply.
On Tuesday, April 5, 2016 at 2:36:09 PM UTC+1, Gabriel Gellner wrote:
>
> you can do the python example as:
>
> a[[1, 4] + range(7, 17, 2)]
> (ignoring the issues that this is not the same range as julia since python
> uses 0-based indices ...)
>
> you don't need to index
you can do the python example as:
a[[1, 4] + range(7, 17, 2)]
(ignoring the issues that this is not the same range as julia since python
uses 0-based indices ...)
you don't need to index with an ndarray, and that way you can get the nice
use of the + operator for concatenate.
Lacking the : for
It's nuts...people complaining about how many key presses it takes to write
\div[tab] and hold up a language that takes np.array([..]) as better...
Sent from my iPhone
> On 5 Apr 2016, at 22:54, DNF wrote:
>
>> On Tuesday, April 5, 2016 at 2:47:15 PM UTC+2, Sisyphuss wrote:
>> np.array([a[i]
On Tuesday, April 5, 2016 at 2:47:15 PM UTC+2, Sisyphuss wrote:
>
> np.array([a[i] for i in [1,2,4] + list(range(7,17,2))])
>
> This works, albeit awkward. Python was not originally designed for
> mathematics.
>
Thanks :) But that this is also my point: I find it mind-boggling that
someone would
np.array([a[i] for i in [1,2,4] + list(range(7,17,2))])
This works, albeit awkward. Python was not originally designed for
mathematics.
On Tue, Apr 5, 2016 at 10:40 AM, DNFwrote:
> Thanks for the suggestion, but that returns a list, not an array. Also I
> wanted a mix of arbitrary indices and a
Thanks for the suggestion, but that returns a list, not an array. Also I
wanted a mix of arbitrary indices and a range (which could be arbitrarily
long). Using your idea, I then tried:
np.array([a[i] for i in [1,2,4, range(7,17,2)]])
but that didn't work. Also it's a bit awkward compared to the
You can use list compression in python
[a[i] for i in [1,2,4,7,9] ]
On Apr 5, 2016 8:55 AM, "DNF" <> wrote:
>
> Typo, I meant to type:
>
> Python 3.5
> a[i*len(a)//n:(i+1)*len(a)//n]
>
> Julia:
> a[1+i*end÷n:(i+1)end÷n]
>
> I'm just learning Python, and must say I find indexing in Python to be
ve
Typo, I meant to type:
Python 3.5
a[i*len(a)//n:(i+1)*len(a)//n]
Julia:
a[1+i*end÷n:(i+1)end÷n]
I'm just learning Python, and must say I find indexing in Python to be very
awkward compared to Julia or Matlab. Do you have any suggestion for how I
should do this in Python?
a[[1; 4; 7:2:15]]
So f
On Saturday, April 2, 2016 at 1:55:55 PM UTC+2, Spiritus Pap wrote:
>
> 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 py
There are only 6 uses of // outside of rationals.jl in base (4 of those are
in mpfr.jl), compared to 187 uses of div, and 22 uses of ÷. (that’s uses,
not definitions, exports, documentation, although the ratios are very
similar).
Looking at packages, it seems also that div is used frequently,
On Monday, April 4, 2016 at 7:27:40 AM UTC-4, Stefan Karpinski wrote:
>
> Number does not imply or assume commutativity. The Quaternions package
> provides a Quaternion type which is a subtype of Number. Rational, however,
> only allows integer numerators and denominators. Since integer
> mult
Yes, let's return to the OP. Note that what the author *really wants* is to
get the i-th potion of an array. Either integer division or 0-based alone
can't solve this problem. a[i*100/n : (i+1)*100/n] needs both features.
As Eric puts it, user-written code can be as efficient as the built-in
code.
It’s also entirely possible to create a macro that lets / do what you (the
OP) want.
@integer_division begin
# in here, 5 / 2 == 2
end
Basically, you’d just traverse the AST recursively and switch all calls to /
for calls to div. (I admit, though I wouldn’t want to do it myself, nor
wo
Number does not imply or assume commutativity. The Quaternions package
provides a Quaternion type which is a subtype of Number. Rational, however,
only allows integer numerators and denominators. Since integer
multiplication is commutative, rational multiplication is too. But I still
think it best
Since supertype(Number) == Any, the most abstract number-like entity that
Julia has to offer with the current hierarchy is Number. Most packages I
have seen that implement number-like types which are outside of the Reals
use Number as their supertype. This is more helpful, generally, than
hav
Rational is currently restricted to numbers: Rational{T<:Number}. I’m
assuming Number implicitly means commutative number (i.e., not Quaternion).
> On 4 Apr 2016, at 8:55 PM, Tim Holy wrote:
>
> On Sunday, April 03, 2016 09:28:28 AM Scott Jones wrote:
>> With \\, would you worry a
On Sunday, April 03, 2016 09:28:28 AM Scott Jones wrote:
> With \\, would you worry about confusion from the fact that in a \\ b, a is
>
> > in
> > the denominator? Especially if it gets called the "integer division
> > operator."
>
> It might confuse some of the mathematicians, used to a \ b as
Why not just add a shortcut in your editor that automatically expands \\ to
*÷?*
On Monday, April 4, 2016 at 7:12:44 PM UTC+10, Scott Jones wrote:
>
>
>
> On Sunday, April 3, 2016 at 12:09:35 PM UTC-4, Tim Holy wrote:
>>
>> Indexing with // is a bit undesirable because 6//3 gets simplified to
>>
On Sunday, April 3, 2016 at 12:09:35 PM UTC-4, Tim Holy wrote:
>
> Indexing with // is a bit undesirable because 6//3 gets simplified to 2//1
> upon
> construction, and there's no reason to pay the cost of that operation.
>
That was Eric's idea - I was strictly talking about integer division,
On Sunday, April 3, 2016 at 12:20:44 PM UTC-4, Stefan Karpinski wrote:
>
> I question the alleged ubiquity of integer division. This is not an
> operation I find myself needing all that often. Of course, everyone's
> programming needs are different, but I just don't find myself wanting the
> int
> 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.
I do not understand why this is re
I came to this thinking it would be about how Julia pedagogy is a little
more difficult than other scripting languages because there are a lot of
details in the advanced features which are normally the points of
conversation for more experienced users. That's a legitimate concern.
However, this
IMHO having the "/" operator return a float was an excellent design
decision in Julia. The amount of time I've seen people waste (with other
languages) tracking down bugs caused by doing a/b with a
> I question the alleged ubiquity of integer division. This is not an
> operation I find myself ne
I question the alleged ubiquity of integer division. This is not an
operation I find myself needing all that often. Of course, everyone's
programming needs are different, but I just don't find myself wanting the
integer quotient of a and b more often than I want to do a/b and get their
ratio as a f
Indexing with // is a bit undesirable because 6//3 gets simplified to 2//1 upon
construction, and there's no reason to pay the cost of that operation.
With \\, would you worry about confusion from the fact that in a \\ b, a is in
the denominator? Especially if it gets called the "integer divisio
Just thinking out loud...
On Sunday, April 3, 2016 at 11:49:33 PM UTC+8, Scott Jones wrote:
>
> What do you think about adding \\ as an integer division operator to Julia?
>
What about just writing some package to allow indexing arrays with
rationals if this is so important to some people? If th
I didn't say that it was. However, I don't think that there is any
evidence for the statement that: "Python community at large consider to be
sufficiently much better", given that only around 1/3 of the community even
uses Python 3 yet.
The big reason (with lots of evidence to support this) was
On Sun, Apr 3, 2016 at 8:50 AM, Scott Jones
wrote:
> 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.
>
The change of division is not the reason people ar
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++ CacheObjectScri
For some reason, my posts are getting sent prematurely! Continuing:
Since the integer division operator // of Python (2&3) and Lua already
means something important in Julia, and \ is also taken, I'd like to
propose \\ as an integer division operator for Julia.
Having to always type \ d i v in
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
Oops, somehow my reply got sent before I finished it!
About the division: I do think that Julia is not consistent with the /
operator. Other operators almost always return something of the same type.
While there is the Unicode character ÷ operator, which does integer
division, that's a pain to
I feel your pain, those two items have been a pain for me and my
colleagues, however, I think Julia is such a flexible language that I have
high hope that both 0-based vs. 1-based indexing and the difference between
row-major vs. column-major can be handled
in a generic fashion, and as Tony has
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 sort
Didn't numpy's `transpose()` function make your life hard?
There's a unicode integer division operator. \div then hit tab, you get ÷.
Many editors have plugins for similar latex-tab-completion to make unicode
math symbols easier to write.
Nearly anything can be implemented as a library in Julia. See
https://github.com/alsam/OffsetArrays.jl,
https://gi
43 matches
Mail list logo
