Hi,
On Sun, Jan 20, 2013 at 6:10 PM, Olivier Delalleau sh...@keba.be wrote:
2013/1/18 Matthew Brett matthew.br...@gmail.com:
Hi,
On Fri, Jan 18, 2013 at 7:58 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Fri, Jan 18, 2013 at 4:39 AM, Olivier Delalleau sh...@keba.be wrote:
2013/1/18 Matthew Brett matthew.br...@gmail.com:
Hi,
On Fri, Jan 18, 2013 at 7:58 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Fri, Jan 18, 2013 at 4:39 AM, Olivier Delalleau sh...@keba.be wrote:
Le vendredi 18 janvier 2013, Chris Barker - NOAA Federal a écrit :
If you
Le vendredi 18 janvier 2013, Chris Barker - NOAA Federal a écrit :
On Thu, Jan 17, 2013 at 5:34 PM, Olivier Delalleau
sh...@keba.bejavascript:;
wrote:
Yes, I do understand that. The difference - as I understand it - is
that back in the day, numeric did not have the the float32 etc
On Fri, Jan 18, 2013 at 4:39 AM, Olivier Delalleau sh...@keba.be wrote:
Le vendredi 18 janvier 2013, Chris Barker - NOAA Federal a écrit :
If you check again the examples in this thread exhibiting surprising /
unexpected behavior, you'll notice most of them are with integers.
The tricky thing
Hi,
On Fri, Jan 18, 2013 at 7:58 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Fri, Jan 18, 2013 at 4:39 AM, Olivier Delalleau sh...@keba.be wrote:
Le vendredi 18 janvier 2013, Chris Barker - NOAA Federal a écrit :
If you check again the examples in this thread exhibiting
Hi,
On Wed, Jan 9, 2013 at 6:07 PM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
On 01/09/2013 06:22 PM, Chris Barker - NOAA Federal wrote:
On Wed, Jan 9, 2013 at 7:09 AM, Nathaniel Smith n...@pobox.com wrote:
This is a general issue applying to data which is read from real-world
On Thu, Jan 17, 2013 at 6:26 AM, Matthew Brett matthew.br...@gmail.com wrote:
I am starting to wonder if we should aim for making
* scalar and array casting rules the same;
* Python int / float scalars become int32 / 64 or float64;
aren't they already? I'm not sure what you are proposing.
On Thu, Jan 17, 2013 at 5:04 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
So in the in the spirit of practicality beats purity -- Id like
accidental upcasting to be hard to do.
and then:
arr = arr + scalar
would yield the same type as:
arr += scalar
so we buy some
Hi,
On Fri, Jan 18, 2013 at 1:04 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Thu, Jan 17, 2013 at 6:26 AM, Matthew Brett matthew.br...@gmail.com
wrote:
I am starting to wonder if we should aim for making
* scalar and array casting rules the same;
* Python int / float
I'd like to echo what Chris is saying. It was a big annoyance with Numeric to
make it so hard to preserve the array type in ordinary expressions.
Perry
On Jan 17, 2013, at 8:04 PM, Chris Barker - NOAA Federal wrote:
On Thu, Jan 17, 2013 at 6:26 AM, Matthew Brett matthew.br...@gmail.com
2013/1/17 Matthew Brett matthew.br...@gmail.com:
Hi,
On Fri, Jan 18, 2013 at 1:04 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Thu, Jan 17, 2013 at 6:26 AM, Matthew Brett matthew.br...@gmail.com
wrote:
I am starting to wonder if we should aim for making
* scalar and
On Thu, Jan 17, 2013 at 5:34 PM, Olivier Delalleau sh...@keba.be wrote:
Yes, I do understand that. The difference - as I understand it - is
that back in the day, numeric did not have the the float32 etc
scalars, so you could not do:
another_array = my_array * np.float32(4.0)
(please
On Tue, Jan 8, 2013 at 9:14 PM, Andrew Collette
andrew.colle...@gmail.com wrote:
Hi Nathaniel,
(Responding to both your emails)
The problem is that rule for arrays - and for every other party of
numpy in general - are that we *don't* pick types based on values.
Numpy always uses input types
On Wed, Jan 9, 2013 at 7:09 AM, Nathaniel Smith n...@pobox.com wrote:
This is a general issue applying to data which is read from real-world
external sources. For example, digitizers routinely represent their
samples as int8's or int16's, and you apply a scale and offset to get
a reading in
Hi Nathaniel,
Sure. But the only reason this is in 1.6 is that the person who made
the change never mentioned it to anyone else, so it wasn't noticed
until after 1.6 came out. If it had gone through proper review/mailing
list discussion (like we're doing now) then it's very unlikely it
would
On 01/09/2013 06:22 PM, Chris Barker - NOAA Federal wrote:
On Wed, Jan 9, 2013 at 7:09 AM, Nathaniel Smith n...@pobox.com wrote:
This is a general issue applying to data which is read from real-world
external sources. For example, digitizers routinely represent their
samples as int8's or
Hi,
On Mon, Jan 7, 2013 at 10:58 PM, Andrew Collette
andrew.colle...@gmail.com wrote:
Hi,
Taking 2) first, in this example:
return self.f[dataset_name][...] + heightmap
assuming it is not going to upcast, would you rather it overflow than
raise an error? Why? The second seems more
Hi,
I think you are voting strongly for the current casting rules, because
they make it less obvious to the user that scalars are different from
arrays.
Maybe this is the source of my confusion... why should scalars be
different from arrays? They should follow the same rules, as closely
as
2013/1/8 Andrew Collette andrew.colle...@gmail.com:
Hi,
I think you are voting strongly for the current casting rules, because
they make it less obvious to the user that scalars are different from
arrays.
Maybe this is the source of my confusion... why should scalars be
different from
On 1/8/2013 1:48 PM, Olivier Delalleau wrote:
As I mentioned in another post, I also agree that it would make things
simpler and safer to just yield the same result as if we were using a
one-element array.
Yes!
Anything else is going to drive people insane,
especially new users.
Alan Isaac
On 8 Jan 2013 17:24, Andrew Collette andrew.colle...@gmail.com wrote:
Hi,
I think you are voting strongly for the current casting rules, because
they make it less obvious to the user that scalars are different from
arrays.
Maybe this is the source of my confusion... why should scalars
On Tue, Jan 8, 2013 at 7:28 PM, Alan G Isaac alan.is...@gmail.com wrote:
On 1/8/2013 1:48 PM, Olivier Delalleau wrote:
As I mentioned in another post, I also agree that it would make things
simpler and safer to just yield the same result as if we were using a
one-element array.
Yes!
Hi Nathaniel,
(Responding to both your emails)
The problem is that rule for arrays - and for every other party of
numpy in general - are that we *don't* pick types based on values.
Numpy always uses input types to determine output types, not input
values.
Yes, of course... array operations
On Tue, 2013-01-08 at 19:59 +, Nathaniel Smith wrote:
On 8 Jan 2013 17:24, Andrew Collette andrew.colle...@gmail.com wrote:
Hi,
I think you are voting strongly for the current casting rules, because
they make it less obvious to the user that scalars are different from
arrays.
On Tue, Jan 8, 2013 at 12:43 PM, Alan G Isaac alan.is...@gmail.com wrote:
New users don't use narrow-width dtypes... it's important to remember
1. I think the first statement is wrong.
Control over dtypes is a good reason for
a new use to consider NumPy.
Absolutely.
Because NumPy supports
2013/1/8 Sebastian Berg sebast...@sipsolutions.net:
On Tue, 2013-01-08 at 19:59 +, Nathaniel Smith wrote:
On 8 Jan 2013 17:24, Andrew Collette andrew.colle...@gmail.com wrote:
Hi,
I think you are voting strongly for the current casting rules, because
they make it less obvious to
2013/1/8 Chris Barker - NOAA Federal chris.bar...@noaa.gov:
On Tue, Jan 8, 2013 at 12:43 PM, Alan G Isaac alan.is...@gmail.com wrote:
New users don't use narrow-width dtypes... it's important to remember
1. I think the first statement is wrong.
Control over dtypes is a good reason for
a new
On 01/08/2013 06:20 PM, Andrew Collette wrote:
Hi,
I think you are voting strongly for the current casting rules, because
they make it less obvious to the user that scalars are different from
arrays.
Maybe this is the source of my confusion... why should scalars be
different from arrays?
On 01/08/2013 10:32 PM, Dag Sverre Seljebotn wrote:
On 01/08/2013 06:20 PM, Andrew Collette wrote:
Hi,
I think you are voting strongly for the current casting rules, because
they make it less obvious to the user that scalars are different from
arrays.
Maybe this is the source of my
Hi Dag,
So you are saying that, for an array x, you want
x + random.randint(10)
to produce an array with a random dtype?
Under the proposed behavior, depending on the dtype of x and the value
from random, this would sometimes add-with-rollover and sometimes
raise ValueError.
Under the
Le mardi 8 janvier 2013, Andrew Collette a écrit :
Hi Dag,
So you are saying that, for an array x, you want
x + random.randint(10)
to produce an array with a random dtype?
Under the proposed behavior, depending on the dtype of x and the value
from random, this would sometimes
Hi,
Keep in mind that in the third option (current 1.6 behavior) the dtype is
large enough to hold the random number, but not necessarily to hold the
result. So for instance if x is an int16 array with only positive values,
the result of this addition may contain negative values (or not,
Le mardi 8 janvier 2013, Andrew Collette a écrit :
Hi,
Keep in mind that in the third option (current 1.6 behavior) the dtype is
large enough to hold the random number, but not necessarily to hold the
result. So for instance if x is an int16 array with only positive values,
the result
Hi Olivier,
Yes, certainly. But in either the proposed or 1.5 behavior, if the
values in x are close to the limits of the type, this can happen also.
My previous email may not have been clear enough, so to be sure: in my above
example, if the random number is 3, then the result may
Hi,
On Fri, Jan 4, 2013 at 5:25 PM, Andrew Collette
andrew.colle...@gmail.com wrote:
I agree the current behavior is confusing. Regardless of the details
of what to do, I suppose my main objection is that, to me, it's really
unexpected that adding a number to an array could result in an
Hi Matthew,
I realized when I thought about it, that I did not have a clear idea
of your exact use case. How does the user specify the thing to add,
and why do you need to avoid an error in the case that adding would
overflow the type? Would you mind giving an idiot-level explanation?
Hi,
On Mon, Jan 7, 2013 at 4:33 PM, Andrew Collette
andrew.colle...@gmail.com wrote:
Hi Matthew,
I realized when I thought about it, that I did not have a clear idea
of your exact use case. How does the user specify the thing to add,
and why do you need to avoid an error in the case that
On Mon, Jan 7, 2013 at 2:17 AM, Olivier Delalleau sh...@keba.be wrote:
Hehe, I didn't even know there was supposed to be a warning for arrays... Ok.
But I'm not convinced that re-using the overflow category is a good
idea, because to me the overflow is typically associated to the result
of an
Hi Matthew,
Just to be clear, you mean you might have something like this?
def my_func('array_name', some_offset):
arr = load_somehow('array_name') # dtype hitherto unknown
return arr + some_offset
? And the problem is that it fails late? Is it really better that
something bad
Hi,
On Mon, Jan 7, 2013 at 8:50 PM, Andrew Collette
andrew.colle...@gmail.com wrote:
Hi Matthew,
Just to be clear, you mean you might have something like this?
def my_func('array_name', some_offset):
arr = load_somehow('array_name') # dtype hitherto unknown
return arr + some_offset
On 2013-01-07 21:50, Andrew Collette wrote:
Hi Matthew,
Just to be clear, you mean you might have something like this?
def my_func('array_name', some_offset):
arr = load_somehow('array_name') # dtype hitherto unknown
return arr + some_offset
? And the problem is that it fails
Hi Matthew,
In this case I think you'd probably agree it would be reasonable to
raise an error - all other things being equal?
No, I don't agree. I want there to be some default semantics I can
rely on. Preferably, I want it to do the same thing it would do if
some_offset were an array with
Hi Dag,
But the default float dtype is double, and default integer dtype is at
least
int32.
So if you rely on NumPy-supplied default behaviour you are fine!
As I mentioned, this caught my interest because people routinely save
data in HDF5 as int8 or int16 to save disk space. It's not at
Hi,
On Mon, Jan 7, 2013 at 9:18 PM, Andrew Collette
andrew.colle...@gmail.com wrote:
Hi Matthew,
In this case I think you'd probably agree it would be reasonable to
raise an error - all other things being equal?
No, I don't agree. I want there to be some default semantics I can
rely on.
Hi Matthew,
Ah - well - I only meant that raising an error in the example would be
no more surprising than raising an error at the python prompt. Do you
agree with that? I mean, if the user knew that:
np.array([1], dtype=np.int8) + 128
would raise an error, they'd probably expect your
Hi,
On Mon, Jan 7, 2013 at 10:03 PM, Andrew Collette
andrew.colle...@gmail.com wrote:
Hi Matthew,
Ah - well - I only meant that raising an error in the example would be
no more surprising than raising an error at the python prompt. Do you
agree with that? I mean, if the user knew that:
Hi,
Taking 2) first, in this example:
return self.f[dataset_name][...] + heightmap
assuming it is not going to upcast, would you rather it overflow than
raise an error? Why? The second seems more explicit and sensible to
me.
Yes, I think this (the 1.5 overflow behavior) was a bit
2013/1/5 Nathaniel Smith n...@pobox.com:
On Fri, Jan 4, 2013 at 5:25 PM, Andrew Collette
andrew.colle...@gmail.com wrote:
I agree the current behavior is confusing. Regardless of the details
of what to do, I suppose my main objection is that, to me, it's really
unexpected that adding a
On Mon, Jan 7, 2013 at 1:43 AM, Olivier Delalleau sh...@keba.be wrote:
2013/1/5 Nathaniel Smith n...@pobox.com:
On Fri, Jan 4, 2013 at 5:25 PM, Andrew Collette
andrew.colle...@gmail.com wrote:
I agree the current behavior is confusing. Regardless of the details
of what to do, I suppose my
2013/1/6 Nathaniel Smith n...@pobox.com:
On Mon, Jan 7, 2013 at 1:43 AM, Olivier Delalleau sh...@keba.be wrote:
2013/1/5 Nathaniel Smith n...@pobox.com:
On Fri, Jan 4, 2013 at 5:25 PM, Andrew Collette
andrew.colle...@gmail.com wrote:
I agree the current behavior is confusing. Regardless of
Hi,
On Fri, Jan 4, 2013 at 4:54 PM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Fri, Jan 4, 2013 at 4:01 PM, Andrew Collette
andrew.colle...@gmail.com wrote:
From a more basic perspective, I think that adding a number to an
array should never raise an exception. I've not used any
On Sat, Jan 5, 2013 at 12:32 PM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Fri, Jan 4, 2013 at 4:54 PM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Fri, Jan 4, 2013 at 4:01 PM, Andrew Collette
andrew.colle...@gmail.com wrote:
From a more basic perspective, I think that
On Sat, Jan 5, 2013 at 3:38 PM, Nathaniel Smith n...@pobox.com wrote:
On Sat, Jan 5, 2013 at 12:32 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Fri, Jan 4, 2013 at 4:54 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Fri, Jan 4, 2013 at 4:01 PM, Andrew Collette
Hi,
On Sat, Jan 5, 2013 at 2:38 PM, Nathaniel Smith n...@pobox.com wrote:
On Sat, Jan 5, 2013 at 12:32 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Fri, Jan 4, 2013 at 4:54 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Fri, Jan 4, 2013 at 4:01 PM, Andrew Collette
On 5 Jan 2013 15:59, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Sat, Jan 5, 2013 at 2:38 PM, Nathaniel Smith n...@pobox.com wrote:
On Sat, Jan 5, 2013 at 12:32 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Fri, Jan 4, 2013 at 4:54 PM, Matthew Brett
Hi,
On Sat, Jan 5, 2013 at 4:16 PM, Nathaniel Smith n...@pobox.com wrote:
On 5 Jan 2013 15:59, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Sat, Jan 5, 2013 at 2:38 PM, Nathaniel Smith n...@pobox.com wrote:
On Sat, Jan 5, 2013 at 12:32 PM, Matthew Brett matthew.br...@gmail.com
On Fri, Jan 4, 2013 at 5:25 PM, Andrew Collette
andrew.colle...@gmail.com wrote:
I agree the current behavior is confusing. Regardless of the details
of what to do, I suppose my main objection is that, to me, it's really
unexpected that adding a number to an array could result in an
2013/1/3 Andrew Collette andrew.colle...@gmail.com:
Another solution is to forget about trying to be smart and always
upcast the operation. That would be my 2nd preferred solution, but it
would make it very annoying to deal with Python scalars (typically
int64 / float64) that would be
Hi Olivier,
A key difference is that with arrays, the dtype is not chosen just
big enough for your data to fit. Either you set the dtype yourself,
or you're using the default inferred dtype (int/float). In both cases
you should know what to expect, and it doesn't depend on the actual
numeric
(sorry, no time for full reply, so for now just answering what I
believe is the main point)
2013/1/4 Andrew Collette andrew.colle...@gmail.com:
The ValueError is here to warn you that the operation may not be doing
what you want. The rollover for smaller values would be the documented
(and
Hi,
On Fri, Jan 4, 2013 at 4:01 PM, Andrew Collette
andrew.colle...@gmail.com wrote:
From a more basic perspective, I think that adding a number to an
array should never raise an exception. I've not used any other
language in which this behavior takes place. In C, you have rollover
On Fri, Jan 4, 2013 at 4:01 PM, Andrew Collette
andrew.colle...@gmail.com wrote:
Hi Olivier,
A key difference is that with arrays, the dtype is not chosen just
big enough for your data to fit. Either you set the dtype yourself,
or you're using the default inferred dtype (int/float). In both
Hi,
(sorry, no time for full reply, so for now just answering what I
believe is the main point)
Thanks for taking the time to discuss/explain this at all... I appreciate it.
The evilness lies in the silent switch between the rollover and upcast
behavior, as in the example I gave previously:
Hi,
In fact in 1.6 there is no assignment of a dtype to '1' which makes
the way 1.6 handles it consistent with the array rules:
I guess I'm a little out of my depth here... what are the array rules?
# Ah-hah, it looks like '1' has a uint8 dtype:
(np.ones(2, dtype=np.uint8) / np.ones(2,
On Wed, Jan 2, 2013 at 11:24 AM, Nathaniel Smith n...@pobox.com wrote:
This discussion seems to have petered out without reaching consensus
one way or another. This seems like an important issue, so I've opened
a bug:
https://github.com/numpy/numpy/issues/2878
Hopefully this way we'll at
Consensus in that bug report seems to be that for array/scalar operations
like:
np.array([1], dtype=np.int8) + 1000 # can't be represented as an int8!
we should raise an error, rather than either silently upcasting the
result (as in 1.6 and 1.7) or silently downcasting the scalar (as in
On 01/04/2013 12:39 AM, Andrew Collette wrote:
Consensus in that bug report seems to be that for array/scalar operations
like:
np.array([1], dtype=np.int8) + 1000 # can't be represented as an int8!
we should raise an error, rather than either silently upcasting the
result (as in 1.6 and
On 3 Jan 2013 23:39, Andrew Collette andrew.colle...@gmail.com wrote:
Consensus in that bug report seems to be that for array/scalar
operations like:
np.array([1], dtype=np.int8) + 1000 # can't be represented as an int8!
we should raise an error, rather than either silently upcasting the
On Fri, Jan 4, 2013 at 12:11 AM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
On 01/04/2013 12:39 AM, Andrew Collette wrote:
Nathaniel Smith wrote:
Consensus in that bug report seems to be that for array/scalar operations
like:
np.array([1], dtype=np.int8) + 1000 # can't be
On 4 Jan 2013 00:39, Peter Cock p.j.a.c...@googlemail.com wrote:
I agree with Dag rather than Andrew, Explicit is better than implicit.
i.e. What Nathaniel described earlier as the apparent consensus.
Since I've actually used NumPy arrays with specific low memory
types, I thought I should
On Fri, Jan 4, 2013 at 12:39 AM, Peter Cock p.j.a.c...@googlemail.com wrote:
Since I've actually used NumPy arrays with specific low memory
types, I thought I should comment about my use case if case it
is helpful:
I've only used the low precision types like np.uint8 (unsigned) where
I
Hi Dag,
If neither is objectively better, I think that is a very good reason to
kick it down to the user. Explicit is better than implicit.
I agree with you, up to a point. However, we are talking about an
extremely common operation that I think most people (myself included)
would not expect
On Fri, Jan 4, 2013 at 12:49 AM, Nathaniel Smith n...@pobox.com wrote:
On 4 Jan 2013 00:39, Peter Cock p.j.a.c...@googlemail.com wrote:
I agree with Dag rather than Andrew, Explicit is better than implicit.
i.e. What Nathaniel described earlier as the apparent consensus.
Since I've actually
2013/1/3 Andrew Collette andrew.colle...@gmail.com:
Hi Dag,
If neither is objectively better, I think that is a very good reason to
kick it down to the user. Explicit is better than implicit.
I agree with you, up to a point. However, we are talking about an
extremely common operation that
Hi Olivier,
Another solution is to forget about trying to be smart and always
upcast the operation. That would be my 2nd preferred solution, but it
would make it very annoying to deal with Python scalars (typically
int64 / float64) that would be upcasting lots of things, potentially
breaking
This discussion seems to have petered out without reaching consensus
one way or another. This seems like an important issue, so I've opened
a bug:
https://github.com/numpy/numpy/issues/2878
Hopefully this way we'll at least not forget about it; also I tried to
summarize the main issues there and
On Tue, Nov 13, 2012 at 6:13 AM, Benjamin Root ben.r...@ou.edu wrote:
On Monday, November 12, 2012, Matthew Brett wrote:
Hi,
On Mon, Nov 12, 2012 at 8:15 PM, Benjamin Root ben.r...@ou.edu wrote:
On Monday, November 12, 2012, Olivier Delalleau wrote:
2012/11/12 Nathaniel Smith
2012/11/12 Matthew Brett matthew.br...@gmail.com
Hi,
On Mon, Nov 12, 2012 at 8:15 PM, Benjamin Root ben.r...@ou.edu wrote:
On Monday, November 12, 2012, Olivier Delalleau wrote:
2012/11/12 Nathaniel Smith n...@pobox.com
On Mon, Nov 12, 2012 at 8:54 PM, Matthew Brett
Hi,
I wanted to check that everyone knows about and is happy with the
scalar casting changes from 1.6.0.
Specifically, the rules for (array, scalar) casting have changed such
that the resulting dtype depends on the _value_ of the scalar.
Mark W has documented these changes here:
On Mon, Nov 12, 2012 at 8:54 PM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
I wanted to check that everyone knows about and is happy with the
scalar casting changes from 1.6.0.
Specifically, the rules for (array, scalar) casting have changed such
that the resulting dtype depends on
Hi,
On Mon, Nov 12, 2012 at 1:11 PM, Nathaniel Smith n...@pobox.com wrote:
On Mon, Nov 12, 2012 at 8:54 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
I wanted to check that everyone knows about and is happy with the
scalar casting changes from 1.6.0.
Specifically, the rules for
On Mon, Nov 12, 2012 at 10:27 PM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Mon, Nov 12, 2012 at 1:11 PM, Nathaniel Smith n...@pobox.com wrote:
On Mon, Nov 12, 2012 at 8:54 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
I wanted to check that everyone knows about and is
2012/11/12 Nathaniel Smith n...@pobox.com
On Mon, Nov 12, 2012 at 8:54 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
I wanted to check that everyone knows about and is happy with the
scalar casting changes from 1.6.0.
Specifically, the rules for (array, scalar) casting have
On Monday, November 12, 2012, Olivier Delalleau wrote:
2012/11/12 Nathaniel Smith n...@pobox.com javascript:_e({}, 'cvml',
'n...@pobox.com');
On Mon, Nov 12, 2012 at 8:54 PM, Matthew Brett
matthew.br...@gmail.comjavascript:_e({}, 'cvml',
'matthew.br...@gmail.com');
wrote:
Hi,
I
On Monday, November 12, 2012, Benjamin Root wrote:
On Monday, November 12, 2012, Olivier Delalleau wrote:
2012/11/12 Nathaniel Smith n...@pobox.com
On Mon, Nov 12, 2012 at 8:54 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
I wanted to check that everyone knows about and is
Hi,
On Mon, Nov 12, 2012 at 8:15 PM, Benjamin Root ben.r...@ou.edu wrote:
On Monday, November 12, 2012, Olivier Delalleau wrote:
2012/11/12 Nathaniel Smith n...@pobox.com
On Mon, Nov 12, 2012 at 8:54 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
I wanted to check that
On Monday, November 12, 2012, Matthew Brett wrote:
Hi,
On Mon, Nov 12, 2012 at 8:15 PM, Benjamin Root ben.r...@ou.edu wrote:
On Monday, November 12, 2012, Olivier Delalleau wrote:
2012/11/12 Nathaniel Smith n...@pobox.com
On Mon, Nov 12, 2012 at 8:54 PM, Matthew Brett
87 matches
Mail list logo
