Fully realising that this discussion has been settled and the convention is
here to stay, I nevertheless feel obsessed to make the remark that there
would have been more elegant solutions. Other languages have been able to
come up with acceptable operators for a binary 'min' or 'max':
https://gc
Just commenting on the lack of anouncement. As all this happend on a
developement branch of Julia which is always a little in flux these things
should not really be anounced. What counts is how the NEWS file looks in
the end.
Am Dienstag, 8. Juli 2014 11:56:12 UTC+2 schrieb Hans W Borchers:
>
>
Has this been announced somewhere? (Frankly,I'm not reading julia-dev on a
regular basis.)
I see that the manual does not reflects this change. See section
"Vectorized Operators and Functions":
Some operators without dots operate elementwise anyway
when one argument is a scalar.
Thes
Le mardi 08 juillet 2014 à 01:51 -0700, Hans W Borchers a écrit :
> What has happened, two months later, to the (in)famous 'dot' notation
> in Julia?
> There was such a convincing discussion that 5 + x shall not be
> correct, so
> I got used to it. When I now by chance try
>
> julia> x = [0.
What has happened, two months later, to the (in)famous 'dot' notation in
Julia?
There was such a convincing discussion that 5 + x shall not be correct, so
I got used to it. When I now by chance try
julia> x = [0.1, 0.2, 0.3];
julia> 5 + x
3-element Array{Float64,1}:
5.1
5
On Mon, May 5, 2014 at 12:53 PM, Ethan Anderes wrote:
> yeah, I can imagine how annoying it is to the developers that all us
> newbies feel like we can chime in on language design:) However, I do think
> its a sign of how natural and inclusive the language feels to the everyday
> user.
>
> BTW: I
yeah, I can imagine how annoying it is to the developers that all us newbies
feel like we can chime in on language design:) However, I do think its a sign
of how natural and inclusive the language feels to the everyday user.
BTW: I like maxof better than pmax, but maybe like .max() better than e
An option we considered and discarded was to introduce a Dim immutable, i.e.,
min(A, Dim(2))
That would not have the performance disadvantage of a keyword argument.
--Tim
On Monday, May 05, 2014 11:24:28 AM Stefan Karpinski wrote:
> The thing I had proposed was
>
> min(A,1) => smallest value
In the github issue it was also proposed to call the multiple argument max
function maxof which is IMHO a little clearer than pmax.
Am Montag, 5. Mai 2014 17:39:22 UTC+2 schrieb Ethan Anderes:
>
> +1 for max() and pmax(). It seems the easiest to write and to interpret.
I think at this point, while the maximum name may not be everyone's
favorite choice, that bikeshed has sailed. Unless we're going to solve this
problem differently, it's going to stay the way it is: max is to maximum as
+ is to sum.
On Mon, May 5, 2014 at 11:39 AM, Ethan Anderes wrote:
> +1 for
+1 for max() and pmax(). It seems the easiest to write and to interpret.
Le lundi 05 mai 2014 à 11:00 -0400, Stefan Karpinski a écrit :
> Since any way you might express the dimensions argument could also be
> a collection to reduce over, I don't think there's any way to squeeze
> all this functionality into a single function unambiguously without
> using keyword argume
The thing I had proposed was
min(A,1) => smallest value of A or 1, whichever is smaller
min(A,1, dim=()) => same shape as A, clamped above at 1
min(A,1, dim=1) => the minimum of each column or 1 as a row matrix
min(A,1, dim=2) => the minimum of each row or 1 as a column matrix
Efficient implemen
I think there's too much ambiguity here to get away with overloading both
in the same function like this.
Say that I have an array A and I want to clamp all elements so that they
are no larger than 1:
A_clamped = min(A, 1)
But it's equally reasonable to want to use
A_col_minima = minimum(A
Since any way you might express the dimensions argument could also be a
collection to reduce over, I don't think there's any way to squeeze all
this functionality into a single function unambiguously without using
keyword arguments. But with a keyword argument, you certainly can do it. We
could eve
After thinking another few moments about it, I think the confusion might be
lifted slightly with some clever use of dispatch. Consider if we'd do
something like this:
max(itr) # returns the largest element in the collection
max(a,b,c...) = max([a,b,c...])
max{N}(A,dims::NTuple{N}) # compute max
Honestly, I've always been dissatisfied with this solution and would have
preferred the keyword-argument solution that I proposed back when we were
discussing this. Having lived with the maximum thing for a while and seen
others encounter it, I'm no less dissatisfied. I still type max when I nee
I'm not saying that the help is not clear, or that the behavior is
surprising, but only that there no information in the words "max" and
"maximum" that allows you to guess or remember their behaviors. I mean one
is just the abbreviation of the other.
For example if I tell you I have two functio
I do think the help texts just from help() on the two functions is quite
clear:
julia> help(maximum)
INFO: Loading help data...
Base.maximum(itr)
Returns the largest element in a collection.
Base.maximum(A, dims)
Compute the maximum value of an array over the given dimensions.
julia> he
I have to say the difference between "max" and "maximum" is pretty much
unintelligible
by just looking at the names. I've read the help for both three days ago
and I already forgot which does what. Maybe "maximum" should be renamed
"maxoverdims" or something of the sort.
Small hint: the easiest way I found to clarify the distinction between
"max" and "maximum", and why it is necessary in the first place, is that
it's the same as that between "the + function" vs "sum", or "the *
function" vs "prod".
(Of course, not checking the region argument in maximum is just
I can't answer for the max/maximum case, but regarding dot notation for
vector operations, it all quite makes sense if one tries to be as strict as
possible with using actual mathematical notation.
For example, having previously defined x = [0.1, 0.2, 0.3], then saying
x + 5
isn't really defi
22 matches
Mail list logo
