Menu
▾
▴
numpy-discussion — Discussion list for all users of Numerical Python
You can subscribe to this list here.
| 2000 |
Jan
(8) |
Feb
(49) |
Mar
(48) |
Apr
(28) |
May
(37) |
Jun
(28) |
Jul
(16) |
Aug
(16) |
Sep
(44) |
Oct
(61) |
Nov
(31) |
Dec
(24) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(56) |
Feb
(54) |
Mar
(41) |
Apr
(71) |
May
(48) |
Jun
(32) |
Jul
(53) |
Aug
(91) |
Sep
(56) |
Oct
(33) |
Nov
(81) |
Dec
(54) |
| 2002 |
Jan
(72) |
Feb
(37) |
Mar
(126) |
Apr
(62) |
May
(34) |
Jun
(124) |
Jul
(36) |
Aug
(34) |
Sep
(60) |
Oct
(37) |
Nov
(23) |
Dec
(104) |
| 2003 |
Jan
(110) |
Feb
(73) |
Mar
(42) |
Apr
(8) |
May
(76) |
Jun
(14) |
Jul
(52) |
Aug
(26) |
Sep
(108) |
Oct
(82) |
Nov
(89) |
Dec
(94) |
| 2004 |
Jan
(117) |
Feb
(86) |
Mar
(75) |
Apr
(55) |
May
(75) |
Jun
(160) |
Jul
(152) |
Aug
(86) |
Sep
(75) |
Oct
(134) |
Nov
(62) |
Dec
(60) |
| 2005 |
Jan
(187) |
Feb
(318) |
Mar
(296) |
Apr
(205) |
May
(84) |
Jun
(63) |
Jul
(122) |
Aug
(59) |
Sep
(66) |
Oct
(148) |
Nov
(120) |
Dec
(70) |
| 2006 |
Jan
(460) |
Feb
(683) |
Mar
(589) |
Apr
(559) |
May
(445) |
Jun
(712) |
Jul
(815) |
Aug
(663) |
Sep
(559) |
Oct
(930) |
Nov
(373) |
Dec
|
|
From: Bill B. <wb...@gm...> - 2006-02-10 00:23:19
|
> Some kind soul added 'svd' and 'inv' to the NumPy/SciPi columns, but thos= e > > don't seem to be defined, at least for the versions of NumPy/SciPy that > I > > have. Are they new? Or are they perhaps defined by a 3rd package in > your > > environment? > > They're in numpy.linalg. Ooooh! Lots of goodies there! > By the way, is there any python way to tell which package a symbol is > coming > > from? > > Check it's __module__ attribute. Ah, perfect. I see it's also mentioned in help(thing) for thing. Thanks. --bb |
|
From: Bill B. <wb...@gm...> - 2006-02-10 00:18:21
|
SSBmaW5kICdudW1iZXIgb2YgYXhlcycgdG8gYmUgZXZlbiBtb3JlIGNvbmZ1c2luZyB0aGFuICdk aW1lbnNpb24nLiAgQm90aApzb3VuZCB0byBtZSBsaWtlIHRoZXkncmUgdGFsa2luZyBhYm91dCB0 aGUgbnVtYmVyIG9mIGNvbXBvbmVudHMgaW4gYSB2ZWN0b3IKKGUuZy4gMy1kaW1lbnNpb25hbCBz cGFjZSB2cyAyLWRpbWVuc2lvbmFsIHNwYWNlKSwgYnV0IGF4ZXMgbW9yZXNvLiAgVGhlCndvcmQg ZGltZW5zaW9uIGhhcyBhIGxvdCBvZiB1c2VzLCBhbmQgaW4gbW9zdCBwcm9ncmFtbWluZyBsYW5n dWFnZXMgYXJyYXlzCmFyZSBkZXNjcmliZWQgYXMgYmVpbmcgb25lLCB0d28gb3IgdGhyZWUgZGlt ZW5zaW9uYWwgZXRjLiAgU28gdGhhdCBtYWtlcwpzZW5zZS4gIEJ1dCBJIGNhbid0IHRoaW5rIG9m IGFueSBjb21tb24gdXNhZ2VzIG9mIGF4aXMgdGhhdCBhcmVuJ3QgcmVsYXRlZAp0byB2ZWN0b3Jz IGluIGEgdmVjdG9yIHNwYWNlLgoKQnV0IHRoYXQncyBqdXN0IG1lLiAgU2VlbXMgbGlrZSB0aGlz IGRlYmF0ZSBwcm9iYWJseSBjYW1lIGFuZCB3ZW50IGEgbG9uZwp0aW1lIGFnby4gIFdoYXQgaXMg cmlnaHQgcHJvYmFibHkgZGVwZW5kcyBtb3N0bHkgb24gd2hhdCBzb3J0IG9mIG1hdGggeW91CnNw ZW5kIHlvdXIgdGltZSBkb2luZy4KCi0tYmIKCk9uIDIvMTAvMDYsIFNhc2hhIDxuZGFycmF5QG1h Yy5jb20+IHdyb3RlOgo+Cj4gT24gMi85LzA2LCBBbGFuIEcgSXNhYWMgPGFpc2FhY0BhbWVyaWNh bi5lZHU+IHdyb3RlOgo+ID4gVW5mb3J0dW5hdGVseSB0aGUgU2NpUHkgYm9vayBjdXJyZW50bHkg dXNlcyB0aGUgdGVybSAncmFuaycKPiA+IGluIHRoZSB0d28gY29uZmxpY3Rpbmcgd2F5cy4gIChJ dCB1c2VzICdyYW5rJyBpbiB0aGUgbGluZWFyCj4gPiBhbGdlYnJhIHNlbnNlIG9ubHkgaW4gdGhl IGRpc2N1c3Npb24gb2YgbHN0c3Egb24gcC4xNDUuKQo+ID4gSXQgbWlnaHQgYmUgaGVscGZ1bCBm b3IgdGhlIHRlbnNvciBzZW5zZSB0byBhbHdheXMgYmUKPiA+IHF1YWxpZmllZCBhcyAndGVuc29y IHJhbmsnPwo+Cj4gQW5vdGhlciBhbHRlcm5hdGl2ZSB3b3VsZCBiZSAibnVtYmVyIG9mIGF4ZXMu IiAgIEkgYWxzbyBmaW5kIGEKPiBnbG9zc2FyeSB1c2VkIGJ5IHRoZSBKIGxhbmd1YWdlIChhbiBB UEwgZGVzY2VuZGFudCkgdXNlZnVsIGluIGFycmF5Cj4gZGlzY3Vzc2lvbnMuIFNlZQo+IDxodHRw Oi8vd3d3Lmpzb2Z0d2FyZS5jb20vYm9va3MvaGVscC9qZm9yYy9nbG9zc2FyeS5odG0gPi4KPgo+ IEhlcmUgaXMgaG93IEogZG9jdW1lbnRhdGlvbiBleHBsYWlucyB0aGUgZGlmZmVyZW5jZSBpbiB0 aGVpcgo+IHRlcm1pbm9sb2d5IGFuZCB0aGF0IG9mIHRoZSBDIGxhbmd1YWdlOiAiV2hhdCBDIGNh bGxzIGFuIG4tZGltZW5zaW9uYWwKPiBhcnJheSBvZiByYW5rIGnXateF12sgaXMgaW4gSiBhbiBh cnJheSBvZiByYW5rIG4gd2l0aCBheGVzIG9mIGxlbmd0aAo+IGksaiyFLGsuIiAgPGh0dHA6Ly93 d3cuanNvZnR3YXJlLmNvbS9ib29rcy9oZWxwL2pmb3JjL2RlY2xhcmF0aW9ucy5odG0+Cj4K |
|
From: <co...@ph...> - 2006-02-10 00:16:11
|
Bill Baxter <wb...@gm...> writes: > Some kind soul added 'svd' and 'inv' to the NumPy/SciPi columns, but those > don't seem to be defined, at least for the versions of NumPy/SciPy that I > have. Are they new? Or are they perhaps defined by a 3rd package in your > environment? They're in numpy.linalg. > By the way, is there any python way to tell which package a symbol is coming > from? Check it's __module__ attribute. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |co...@ph... |
|
From: Bill B. <wb...@gm...> - 2006-02-10 00:06:52
|
Some kind soul added 'svd' and 'inv' to the NumPy/SciPi columns, but those don't seem to be defined, at least for the versions of NumPy/SciPy that I have. Are they new? Or are they perhaps defined by a 3rd package in you= r environment? By the way, is there any python way to tell which package a symbol is comin= g from? --bb |
|
From: Bill B. <wb...@gm...> - 2006-02-10 00:01:40
|
Oh, yeh. I can see the problem with the phrase "rank of a matrix". It does sound like it means the linear algebra rank of rank/nullity fame. I changed the description on the page a bit. Thanks for catching that. --bb On 2/9/06, Bruce Southey <bso...@gm...> wrote: > > Hi, > The example of ndim to give the rank is not the same as the Matlab > function rank(a). See > http://en.wikipedia.org/wiki/Rank_of_a_matrix for definition of rank > that I would think that most people would use if they use Matlab and > is provided by rank(a). > > I have not used the latest numpy but the equivalent function is not > present in numarray/Numeric (to my knowledge) so you have to find some > other way like using svd. > > Regards > Bruce > > On 2/9/06, Bill Baxter <wb...@gm...> wrote: > > I added some content to the "NumPy/SciPy for Matlab users" page on the > scipy wiki. > > > > But my knowledge of NumPy/SciPy isn't sufficient to fill in the whole > chart of equivalents that I laid out. > > If folks who know both could browse by and maybe fill in a blank or two= , > that would be great. I think this will be a helpful "getting started" pa= ge > for newbies to NumPy coming from matlab, like me. One of the most > frustrating things is when you sit down and can't figure out how to do th= e > most basic things that do in your sleep in another environment (like maki= ng > a column vector). So hopefully this page will help. > > > > The URL is : http://www.scipy.org/Wiki/NumPy_for_Matlab_Addicts > > > > Thanks, > > Bill Baxter > > > |
|
From: Vidar G. <vid...@37...> - 2006-02-09 23:59:38
|
===== Original message from Gary Ruben | 9 Feb 2006: > Vidar's documentation is under a GNU Free Documentation License. This is > probably a problem with incorporating it directly into the scipy site, > although Vidar was at one point happy to incorporate the MATLAB parts this was not the intention when i picked an open license for it. i'm not that familiar with the legal stuff, and i guess when first used a GPL/GFDL it always has to be? i also considered CC, but didn't want to spend a lot of time digging into legal stuff: i wanted to make the reference available and reusable to anyone. i don't mind, i wanted to achieve openness and encourage contributions and derivations, and be able to use these to improve and update the original reference. i need to update it with the new NumPy package, but i haven't taken the time to buy the manual and start looking into it yet. will including NumPy commands be a problem related to licensing on the NumPy documentation? also, i'd prefer to publish it on a more appropriate site (like scipy.org, sourceforge.net, or wherever useful) when i feel the documents are more complete. but note that this is not really a Numerical Python and Matlab thing, but a framework to get from math environment a to b. it could also (when i include NumPy) help transition between Numeric/numarray/NumPy: this can easily be generated as a separate reference (i use XSL and LaTeX). (although i did this to support my own transition from Matlab to non-commercial alternatives, e.g. Python and R/RPy, Gnuplot, etc for plotting.) thanks for cross-posting this to me, Gary. i'm jumping right into this list, so please be indulgent if i seem uninformed on late talks here. A brief observation on "NumPy for Matlab Addicts": The section "Some Key Differences" says nothing about the amount of routines found in Matlab toolboxes for Optimization, Control engineering, Wavelets, etc. for these there are no real alternatives. kind regards, Vidar Bronken Gundersen |
|
From: Tim H. <tim...@co...> - 2006-02-09 22:45:12
|
Pearu Peterson wrote: > > > On Thu, 9 Feb 2006, Tim Hochberg wrote: > >> I had this fantasy that default_lib_dirs would get picked up >> automagically; however that does not happen. I still ended up putting: >> >> from numpy.distutils import system_info >> library_dirs = system_info.default_lib_dirs >> result = >> config_cmd.try_run(tc,include_dirs=[python_include], >> library_dirs=library_dirs) >> >> into setup.py. Is that acceptable? It's not very elegant. > > > No, don't use system_info.default_lib_dirs. > > Use distutils.sysconfig.get_python_lib() to get the directory that > contains Python library. That's the wrong library. Get_python_lib gives you the location of the python standard library, not the location of python24.lib <cid:par...@co...>. The former being python24/Lib (or python24/Lib/site-packages depending what options you feed get_python_lib) 'and the latter being python24/libs on my box. -tim |
|
From: Pearu P. <pe...@sc...> - 2006-02-09 22:34:16
|
On Thu, 9 Feb 2006, Tim Hochberg wrote: > I had this fantasy that default_lib_dirs would get picked up > automagically; however that does not happen. I still ended up putting: > > from numpy.distutils import system_info > library_dirs = system_info.default_lib_dirs > result = config_cmd.try_run(tc,include_dirs=[python_include], > library_dirs=library_dirs) > > into setup.py. Is that acceptable? It's not very elegant. No, don't use system_info.default_lib_dirs. Use distutils.sysconfig.get_python_lib() to get the directory that contains Python library. Pearu |
|
From: Tim H. <tim...@co...> - 2006-02-09 21:43:45
|
Travis Oliphant wrote: > Tim Hochberg wrote: > >> That is, not only did all of the incorrect end cases go away, it >> actually got marginally faster. Why it got faster I can't say, >> there's not much to be gained in second guessing an optimizing >> compiler. It's quite possible that this may be compiler dependant, so >> I'd be interested in the results with other compilers. Also, I only >> sampled a small chunk of the input space of arange, so if you have >> some other failing input values, please send them to me and I can >> test them and see if this change fixes them also. >> >> I didn't mess with the complex version of fill yet. Is that just >> there to support arange(0, 100, 2, dtype=complex), or is there some >> other use for _fill besides arange? > > > > This is a simple change and one we could easily do. The complex > versions are there to support complex arange? There are no other uses > "currently" for fill. Just for truth in advertising, after the last svn update I did, the speed advantage mostly went away: # baseline arange(10000) took 2.27355292363 seconds for 100000 reps arange(10000.0) took 4.39404812623 seconds for 100000 reps arange(10000,dtype=complex) took 4.01601209092 seconds for 100000 reps # multiply instead of repeated add. arange(10000) took 2.20859410903 seconds for 100000 reps arange(10000.0) took 4.34652784083 seconds for 100000 reps arange(10000,dtype=complex) took 6.02266433304 seconds for 100000 reps I'm not sure if this is a result of the changes that you made stripping out the unneeded 'i' or if my machine was in some sort of different state or what. Note that I modified the complex fills as well now and they are much slower. Is it possible for delta to be complex? If not, we could speed up the complex case a little by exploiting the fact that delta.real is always zero. If in, in addition, we can assume both that start.imag is zero and that the array is zeroed out to start with, we could speed things up some more. This seems like a no-brainer for floats (and a noop for ints) since it alleviates the problem of arange(start,stop,step)[-1] sometimes being >= stop without costing anything performance wise. (I don't know that it cures the problem, but it seems to make it a lot less likely). For complex the situation is more, uh, complex. I'd like to make it since in general I'd rather be right than fast. Still, it's a signifigant performance hit in this case. Thoughts? -tim > Although you could use it with two equal values to fill an array with > the same thing quickly. I have yet to test a version of ones using > fill against the current implementation which adds 1 to a zeros array. > > Thanks for the changes. > > -Travis > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > |
|
From: Sasha <nd...@ma...> - 2006-02-09 20:50:37
|
T24gMi85LzA2LCBBbGFuIEcgSXNhYWMgPGFpc2FhY0BhbWVyaWNhbi5lZHU+IHdyb3RlOgo+IFVu Zm9ydHVuYXRlbHkgdGhlIFNjaVB5IGJvb2sgY3VycmVudGx5IHVzZXMgdGhlIHRlcm0gJ3Jhbmsn Cj4gaW4gdGhlIHR3byBjb25mbGljdGluZyB3YXlzLiAgKEl0IHVzZXMgJ3JhbmsnIGluIHRoZSBs aW5lYXIKPiBhbGdlYnJhIHNlbnNlIG9ubHkgaW4gdGhlIGRpc2N1c3Npb24gb2YgbHN0c3Egb24g cC4xNDUuKQo+IEl0IG1pZ2h0IGJlIGhlbHBmdWwgZm9yIHRoZSB0ZW5zb3Igc2Vuc2UgdG8gYWx3 YXlzIGJlCj4gcXVhbGlmaWVkIGFzICd0ZW5zb3IgcmFuayc/CgpBbm90aGVyIGFsdGVybmF0aXZl IHdvdWxkIGJlICJudW1iZXIgb2YgYXhlcy4iICAgSSBhbHNvIGZpbmQgYQpnbG9zc2FyeSB1c2Vk IGJ5IHRoZSBKIGxhbmd1YWdlIChhbiBBUEwgZGVzY2VuZGFudCkgdXNlZnVsIGluIGFycmF5CmRp c2N1c3Npb25zLiBTZWUKPGh0dHA6Ly93d3cuanNvZnR3YXJlLmNvbS9ib29rcy9oZWxwL2pmb3Jj L2dsb3NzYXJ5Lmh0bT4uCgpIZXJlIGlzIGhvdyBKIGRvY3VtZW50YXRpb24gZXhwbGFpbnMgdGhl IGRpZmZlcmVuY2UgaW4gdGhlaXIKdGVybWlub2xvZ3kgYW5kIHRoYXQgb2YgdGhlIEMgbGFuZ3Vh Z2U6ICJXaGF0IEMgY2FsbHMgYW4gbi1kaW1lbnNpb25hbAphcnJheSBvZiByYW5rIGnXateF12sg aXMgaW4gSiBhbiBhcnJheSBvZiByYW5rIG4gd2l0aCBheGVzIG9mIGxlbmd0aAppLGoshSxrLiIg IDxodHRwOi8vd3d3Lmpzb2Z0d2FyZS5jb20vYm9va3MvaGVscC9qZm9yYy9kZWNsYXJhdGlvbnMu aHRtPgo= |
|
From: Travis O. <oli...@ie...> - 2006-02-09 20:32:27
|
Tim Hochberg wrote: > > > There's a shallow error in system_info.py > > File "C:\Documents and > Settings\End-user\Desktop\numpy\svn\numpy\numpy\distutils\system_info.py", > > line 118, in ? > default_lib_dirs = ['C:\\', > NameError: name 'join' is not defined > > Just replacing join with os.path.join fixed that. However, it didn't > help. I had this fantasy that default_lib_dirs would get picked up > automagically; however that does not happen. I still ended up putting: > > from numpy.distutils import system_info > library_dirs = system_info.default_lib_dirs > result = > config_cmd.try_run(tc,include_dirs=[python_include], > library_dirs=library_dirs) > > into setup.py. Is that acceptable? It's not very elegant. I think it's probably O.K. as long as it doesn't produce errors on other systems (and it doesn't on mine). > > The changes to setup.py in random and the M_PI, seem to have worked > since with the changes above it compiles and passes all of the tests > except for the previously mentioned test_minrelpath. > I thought I fixed minrelpath too by doing a search and replace. Perhaps this did not help. -Travis |
|
From: Travis O. <oli...@ie...> - 2006-02-09 20:29:22
|
Tim Hochberg wrote: > That is, not only did all of the incorrect end cases go away, it > actually got marginally faster. Why it got faster I can't say, there's > not much to be gained in second guessing an optimizing compiler. It's > quite possible that this may be compiler dependant, so I'd be > interested in the results with other compilers. Also, I only sampled a > small chunk of the input space of arange, so if you have some other > failing input values, please send them to me and I can test them and > see if this change fixes them also. > > I didn't mess with the complex version of fill yet. Is that just there > to support arange(0, 100, 2, dtype=complex), or is there some other > use for _fill besides arange? This is a simple change and one we could easily do. The complex versions are there to support complex arange? There are no other uses "currently" for fill. Although you could use it with two equal values to fill an array with the same thing quickly. I have yet to test a version of ones using fill against the current implementation which adds 1 to a zeros array. Thanks for the changes. -Travis |
|
From: Tim H. <tim...@co...> - 2006-02-09 18:33:52
|
Travis Oliphant wrote:
> Tim Hochberg wrote:
>
>>>
>>>
>>> I'm trying to incorporate your changes.
>>
>>
>>
>>
>> Great.
>>
>>
>> OK, we'll have to work out something that works for both. The issue
>> here on windows is that compiling the testcode requires python.lib,
>> and it doesn't get found unless that directory is specified. The
>> problem is perhaps related to the following comment in system_info.py
>>
>> if sys.platform == 'win32': # line 116
>> default_lib_dirs = ['C:\\'] # probably not very helpful...
>
>
>
> I added the change you made in setup.py to default_lib_dirs, here.
> See if this fixes it.
>
>>>
>>> 3) For the setup.py file in random you are using Advapi for all
>>> win32 platforms. But, this seems to be a windows NT file
>>
>>
>>
>> I'm compiling on XP FWIW.
>>
>>> or at least only needed when compiling with certain compilers.
>>> Mingw32 built just fine without it. So, I'm not sure how to handle
>>> this.
>>
>>
> I see now. On _WIN32 platforms it's using the registry instead of the
> file system to store things. I modified the random/setup.py script to
> test for _WIN32 in the compiler and add the dll to the list of
> libraries if it is found. I'm also reading the configuration file to
> determine MATHLIB.
>
> Can you try out the new SVN and see if it builds for you without
> modification.
There's a shallow error in system_info.py
File "C:\Documents and
Settings\End-user\Desktop\numpy\svn\numpy\numpy\distutils\system_info.py",
line 118, in ?
default_lib_dirs = ['C:\\',
NameError: name 'join' is not defined
Just replacing join with os.path.join fixed that. However, it didn't
help. I had this fantasy that default_lib_dirs would get picked up
automagically; however that does not happen. I still ended up putting:
from numpy.distutils import system_info
library_dirs = system_info.default_lib_dirs
result =
config_cmd.try_run(tc,include_dirs=[python_include],
library_dirs=library_dirs)
into setup.py. Is that acceptable? It's not very elegant.
The changes to setup.py in random and the M_PI, seem to have worked
since with the changes above it compiles and passes all of the tests
except for the previously mentioned test_minrelpath.
-tim
|
|
From: Tim H. <tim...@co...> - 2006-02-09 17:46:32
|
Travis Oliphant wrote:
> Tim Hochberg wrote:
>
>>>
>>
>>
>> I see that Travis has vetoed this in any event, but perhaps we should
>> fix up the fill functions to be more accurate and maybe most of the
>> problem would just magically go away.
>
>
>
> To do something different than arange has always done we need a new
> function, not change what arange does and thus potentially break lots
> of code.
>
> How do you propose to make the fill funtions more accurate? I'm
> certainly willing to see improvements there.
OK, I experimented with. I replaced the code for @NAME@_fill in
arraytypes.inc.src with:
/**begin repeat
#NAME=BYTE,UBYTE,SHORT,USHORT,INT,UINT,LONG,ULONG,LONGLONG,ULONGLONG,FLOAT,DOUBLE,LONGDOUBLE#
#typ=byte,ubyte,short,ushort,int,uint,long,ulong,longlong,ulonglong,float,double,longdouble#
*/
static void
@NAME@_fill(@typ@ *buffer, intp length, void *ignored)
{
intp i;
@typ@ start = buffer[0];
@typ@ delta = buffer[1];
delta -= start;
buffer += 2;
for (i=2; i<length; i++, buffer++) {
*buffer = start + i*delta;
}
}
/**end repeat**/
I characterized the change with the little attached benchmark. Before
the change the output was:
arange(0, 100.65000000000001, 0.14999999999999999) failed 100.65 >=
100.65
arange(0, 100.68000000000001, 0.12) failed 100.68 >= 100.68
arange(0, 100.65000000000001, 0.074999999999999997) failed 100.65 >=
100.65
arange(0, 100.26000000000001, 0.059999999999999998) failed 100.26 >=
100.26
arange(0, 100.62, 0.059999999999999998) failed 100.62 >= 100.62
arange(0, 100.68000000000001, 0.059999999999999998) failed 100.68 >=
100.68
arange(0, 100.98, 0.059999999999999998) failed 100.98 >= 100.98
arange(0, 100.5, 0.031914893617021274) failed 100.5 >= 100.5
arange(10000) took 2.25123220968 seconds for 100000 reps
arange(10000.0) took 4.31864636427 seconds for 100000 reps
After the change:
arange(10000) took 1.82795662577 seconds for 100000 reps
arange(10000.0) took 3.93278363591 seconds for 100000 reps
That is, not only did all of the incorrect end cases go away, it
actually got marginally faster. Why it got faster I can't say, there's
not much to be gained in second guessing an optimizing compiler. It's
quite possible that this may be compiler dependant, so I'd be interested
in the results with other compilers. Also, I only sampled a small chunk
of the input space of arange, so if you have some other failing input
values, please send them to me and I can test them and see if this
change fixes them also.
I didn't mess with the complex version of fill yet. Is that just there
to support arange(0, 100, 2, dtype=complex), or is there some other use
for _fill besides arange?
Regards,
-tim
|
|
From: Travis O. <oli...@ie...> - 2006-02-09 17:29:14
|
Tim Hochberg wrote: >> >> >> I'm trying to incorporate your changes. > > > > Great. > > > OK, we'll have to work out something that works for both. The issue > here on windows is that compiling the testcode requires python.lib, > and it doesn't get found unless that directory is specified. The > problem is perhaps related to the following comment in system_info.py > > if sys.platform == 'win32': # line 116 > default_lib_dirs = ['C:\\'] # probably not very helpful... I added the change you made in setup.py to default_lib_dirs, here. See if this fixes it. >> >> 3) For the setup.py file in random you are using Advapi for all win32 >> platforms. But, this seems to be a windows NT file > > > I'm compiling on XP FWIW. > >> or at least only needed when compiling with certain compilers. >> Mingw32 built just fine without it. So, I'm not sure how to handle >> this. > I see now. On _WIN32 platforms it's using the registry instead of the file system to store things. I modified the random/setup.py script to test for _WIN32 in the compiler and add the dll to the list of libraries if it is found. I'm also reading the configuration file to determine MATHLIB. Can you try out the new SVN and see if it builds for you without modification. -Travis |
|
From: Andrew S. <str...@as...> - 2006-02-09 16:59:21
|
Martin Wiechert wrote: >Hi list, > >I'm trying to build an C extension, which uses arrays. It builds, and I can >import it from python, but the very first call to a numpy function > > ea = (PyObject *) PyArray_DescrFromType (PyArray_INT); > >gives me a segfault. > >I have absolutely no clue, but > >nm -l mymodule.so | grep rray > >gives > >000026a0 b >PyArray_API /usr/lib/python2.4/site-packages/numpy/core/include/numpy/__multiarray_api.h:316 > >and this line reads > >static void **PyArray_API=NULL; > >which looks suspicious to me. Something wrong with my setup.py? > >Any suggestions? > > Did you do import_array() beforehand? |
|
From: Tim H. <tim...@co...> - 2006-02-09 16:29:57
|
Travis Oliphant wrote:
> Tim Hochberg wrote:
>
>> I'm attaching the two modified setup files. The first is
>> numpy/core/setup.py and the second is numpy/random/setup.py. I tried
>> to keep the modifications as minimal as possible. With these two
>> setup files, and adding M_PI to numpy\random\mtrand\distributions.c,
>> numpy compiles fine and passes all tests except for the
>> test_minrelpath path I mentioned in my last message.
>
>
>
> I'm trying to incorporate your changes.
Great.
> 1) M_PI was easy to fix.
>
> 2) In the core/setup.py file you sent you add the line:
>
> python_libs = join(distutils.sysconfig.EXEC_PREFIX, 'libs')
>
> I'm not sure what this is supposed to do. What problem does it fix on
> your system? It makes no sence on mine as this becomes
>
> python_libs = '/usr/libs'
>
> which is not a directory.
OK, we'll have to work out something that works for both. The issue here
on windows is that compiling the testcode requires python.lib, and it
doesn't get found unless that directory is specified. The problem is
perhaps related to the following comment in system_info.py
if sys.platform == 'win32': # line 116
default_lib_dirs = ['C:\\'] # probably not very helpful...
In any event, it does seem like there should be a better way to find
where python.lib lives, but I couldn't find it in my perusal of the
distutils docs.
>
> 3) For the setup.py file in random you are using Advapi for all win32
> platforms. But, this seems to be a windows NT file
I'm compiling on XP FWIW.
> or at least only needed when compiling with certain compilers.
> Mingw32 built just fine without it. So, I'm not sure how to handle
> this.
My guess, and it's only a gues because I use neither mingw or the
windows crypto stuff, is that defines are set differently by mingw so
that the parts that need that library are not being compiled when you
use mingw. The code in question is all gaurded by:
#ifdef _WIN32
#ifndef RK_NO_WINCRYPT
As far as I can tell, RK_NO_WINCRYPT never gets defined anywhere, so the
important test is for _WIN32. So, does mingw define _WIN32? If it does
not, then that's what's going on. In that case, the proper test is
probably to check if _WIN32 is defined by the compiler in question and
include Advapi only then. If it does define _WIN32, then I dunno!
-tim
|
|
From: Travis O. <oli...@ie...> - 2006-02-09 16:10:27
|
Tim Hochberg wrote:
> I'm attaching the two modified setup files. The first is
> numpy/core/setup.py and the second is numpy/random/setup.py. I tried
> to keep the modifications as minimal as possible. With these two setup
> files, and adding M_PI to numpy\random\mtrand\distributions.c, numpy
> compiles fine and passes all tests except for the test_minrelpath path
> I mentioned in my last message.
I'm trying to incorporate your changes.
1) M_PI was easy to fix.
2) In the core/setup.py file you sent you add the line:
python_libs = join(distutils.sysconfig.EXEC_PREFIX, 'libs')
I'm not sure what this is supposed to do. What problem does it fix on
your system? It makes no sence on mine as this becomes
python_libs = '/usr/libs'
which is not a directory.
3) For the setup.py file in random you are using Advapi for all win32
platforms. But, this seems to be a windows NT file or at least only
needed when compiling with certain compilers. Mingw32 built just fine
without it. So, I'm not sure how to handle this.
Suggestions?
-Travis
>
> -tim
>
>------------------------------------------------------------------------
>
>
>import imp
>import os
>import sys
>import distutils.sysconfig
>from os.path import join
>from glob import glob
>from distutils.dep_util import newer,newer_group
>
>def configuration(parent_package='',top_path=None):
> from numpy.distutils.misc_util import Configuration,dot_join
> from numpy.distutils.system_info import get_info
>
> config = Configuration('core',parent_package,top_path)
> local_dir = config.local_path
> codegen_dir = join(local_dir,'code_generators')
>
> generate_umath_py = join(codegen_dir,'generate_umath.py')
> n = dot_join(config.name,'generate_umath')
> generate_umath = imp.load_module('_'.join(n.split('.')),
> open(generate_umath_py,'U'),generate_umath_py,
> ('.py','U',1))
>
> header_dir = join(*(config.name.split('.')+['include','numpy']))
>
> def generate_config_h(ext, build_dir):
> target = join(build_dir,'config.h')
> if newer(__file__,target):
> config_cmd = config.get_config_cmd()
> print 'Generating',target
> #
> tc = generate_testcode(target)
> from distutils import sysconfig
> python_include = sysconfig.get_python_inc()
> python_libs = join(distutils.sysconfig.EXEC_PREFIX, 'libs')
> result = config_cmd.try_run(tc,include_dirs=[python_include], library_dirs=[python_libs])
> if not result:
> raise "ERROR: Failed to test configuration"
> moredefs = []
>
> #
> mathlibs = []
> tc = testcode_mathlib()
> mathlibs_choices = [[],['m'],['cpml']]
> mathlib = os.environ.get('MATHLIB')
> if mathlib:
> mathlibs_choices.insert(0,mathlib.split(','))
> for libs in mathlibs_choices:
> if config_cmd.try_run(tc,libraries=libs):
> mathlibs = libs
> break
> else:
> raise "math library missing; rerun setup.py after setting the MATHLIB env variable"
> ext.libraries.extend(mathlibs)
> moredefs.append(('MATHLIB',','.join(mathlibs)))
>
> libs = mathlibs
> kws_args = {'libraries':libs,'decl':0,'headers':['math.h']}
> if config_cmd.check_func('expl', **kws_args):
> moredefs.append('HAVE_LONGDOUBLE_FUNCS')
> if config_cmd.check_func('expf', **kws_args):
> moredefs.append('HAVE_FLOAT_FUNCS')
> if config_cmd.check_func('log1p', **kws_args):
> moredefs.append('HAVE_LOG1P')
> if config_cmd.check_func('expm1', **kws_args):
> moredefs.append('HAVE_EXPM1')
> if config_cmd.check_func('asinh', **kws_args):
> moredefs.append('HAVE_INVERSE_HYPERBOLIC')
> if config_cmd.check_func('atanhf', **kws_args):
> moredefs.append('HAVE_INVERSE_HYPERBOLIC_FLOAT')
> if config_cmd.check_func('atanhl', **kws_args):
> moredefs.append('HAVE_INVERSE_HYPERBOLIC_LONGDOUBLE')
> if config_cmd.check_func('isnan', **kws_args):
> moredefs.append('HAVE_ISNAN')
> if config_cmd.check_func('isinf', **kws_args):
> moredefs.append('HAVE_ISINF')
>
> if sys.version[:3] < '2.4':
> kws_args['headers'].append('stdlib.h')
> if config_cmd.check_func('strtod', **kws_args):
> moredefs.append(('PyOS_ascii_strtod', 'strtod'))
>
> if moredefs:
> target_f = open(target,'a')
> for d in moredefs:
> if isinstance(d,str):
> target_f.write('#define %s\n' % (d))
> else:
> target_f.write('#define %s %s\n' % (d[0],d[1]))
> target_f.close()
> else:
> mathlibs = []
> target_f = open(target)
> for line in target_f.readlines():
> s = '#define MATHLIB'
> if line.startswith(s):
> value = line[len(s):].strip()
> if value:
> mathlibs.extend(value.split(','))
> target_f.close()
>
> ext.libraries.extend(mathlibs)
>
> incl_dir = os.path.dirname(target)
> if incl_dir not in config.numpy_include_dirs:
> config.numpy_include_dirs.append(incl_dir)
>
> config.add_data_files((header_dir,target))
> return target
>
> def generate_api_func(header_file, module_name):
> def generate_api(ext,build_dir):
> target = join(build_dir, header_file)
> script = join(codegen_dir, module_name + '.py')
> if newer(script, target):
> sys.path.insert(0, codegen_dir)
> try:
> m = __import__(module_name)
> print 'executing',script
> m.generate_api(build_dir)
> finally:
> del sys.path[0]
> config.add_data_files((header_dir,target))
> return target
> return generate_api
>
> generate_array_api = generate_api_func('__multiarray_api.h',
> 'generate_array_api')
> generate_ufunc_api = generate_api_func('__ufunc_api.h',
> 'generate_ufunc_api')
>
> def generate_umath_c(ext,build_dir):
> target = join(build_dir,'__umath_generated.c')
> script = generate_umath_py
> if newer(script,target):
> f = open(target,'w')
> f.write(generate_umath.make_code(generate_umath.defdict,
> generate_umath.__file__))
> f.close()
> return []
>
> config.add_data_files(join('include','numpy','*.h'))
> config.add_include_dirs('src')
>
> config.numpy_include_dirs.extend(config.paths('include'))
>
> deps = [join('src','arrayobject.c'),
> join('src','arraymethods.c'),
> join('src','scalartypes.inc.src'),
> join('src','arraytypes.inc.src'),
> join('src','_signbit.c'),
> join('src','_isnan.c'),
> join('include','numpy','*object.h'),
> join(codegen_dir,'genapi.py'),
> join(codegen_dir,'*.txt')
> ]
>
> config.add_extension('multiarray',
> sources = [join('src','multiarraymodule.c'),
> generate_config_h,
> generate_array_api,
> join('src','scalartypes.inc.src'),
> join('src','arraytypes.inc.src'),
> join(codegen_dir,'generate_array_api.py'),
> join('*.py')
> ],
> depends = deps,
> )
>
> config.add_extension('umath',
> sources = [generate_config_h,
> join('src','umathmodule.c.src'),
> generate_umath_c,
> generate_ufunc_api,
> join('src','scalartypes.inc.src'),
> join('src','arraytypes.inc.src'),
> ],
> depends = [join('src','ufuncobject.c'),
> generate_umath_py,
> join(codegen_dir,'generate_ufunc_api.py'),
> ]+deps,
> )
>
> config.add_extension('_sort',
> sources=[join('src','_sortmodule.c.src'),
> generate_config_h,
> generate_array_api,
> ],
> )
>
> # Configure blasdot
> blas_info = get_info('blas_opt',0)
> #blas_info = {}
> def get_dotblas_sources(ext, build_dir):
> if blas_info:
> return ext.depends[:1]
> return None # no extension module will be built
>
> config.add_extension('_dotblas',
> sources = [get_dotblas_sources],
> depends=[join('blasdot','_dotblas.c'),
> join('blasdot','cblas.h'),
> ],
> include_dirs = ['blasdot'],
> extra_info = blas_info
> )
>
>
> config.add_data_dir('tests')
> config.make_svn_version_py()
>
> return config
>
>def testcode_mathlib():
> return """\
>/* check whether libm is broken */
>#include <math.h>
>int main(int argc, char *argv[])
>{
> return exp(-720.) > 1.0; /* typically an IEEE denormal */
>}
>"""
>
>import sys
>def generate_testcode(target):
> if sys.platform == 'win32':
> target = target.replace('\\','\\\\')
> testcode = [r'''
>#include <Python.h>
>#include <limits.h>
>#include <stdio.h>
>
>int main(int argc, char **argv)
>{
>
> FILE *fp;
>
> fp = fopen("'''+target+'''","w");
> ''']
>
> c_size_test = r'''
>#ifndef %(sz)s
> fprintf(fp,"#define %(sz)s %%d\n", sizeof(%(type)s));
>#else
> fprintf(fp,"/* #define %(sz)s %%d */\n", %(sz)s);
>#endif
>'''
> for sz, t in [('SIZEOF_SHORT', 'short'),
> ('SIZEOF_INT', 'int'),
> ('SIZEOF_LONG', 'long'),
> ('SIZEOF_FLOAT', 'float'),
> ('SIZEOF_DOUBLE', 'double'),
> ('SIZEOF_LONG_DOUBLE', 'long double'),
> ('SIZEOF_PY_INTPTR_T', 'Py_intptr_t'),
> ]:
> testcode.append(c_size_test % {'sz' : sz, 'type' : t})
>
> testcode.append('#ifdef PY_LONG_LONG')
> testcode.append(c_size_test % {'sz' : 'SIZEOF_LONG_LONG',
> 'type' : 'PY_LONG_LONG'})
> testcode.append(c_size_test % {'sz' : 'SIZEOF_PY_LONG_LONG',
> 'type' : 'PY_LONG_LONG'})
>
>
> testcode.append(r'''
>#else
> fprintf(fp, "/* PY_LONG_LONG not defined */\n");
>#endif
>#ifndef CHAR_BIT
> {
> unsigned char var = 2;
> int i=0;
> while (var >= 2) {
> var = var << 1;
> i++;
> }
> fprintf(fp,"#define CHAR_BIT %d\n", i+1);
> }
>#else
> fprintf(fp, "/* #define CHAR_BIT %d */\n", CHAR_BIT);
>#endif
> fclose(fp);
> return 0;
>}
>''')
> testcode = '\n'.join(testcode)
> return testcode
>
>if __name__=='__main__':
> from numpy.distutils.core import setup
> setup(**configuration(top_path='').todict())
>
>
>------------------------------------------------------------------------
>
>import sys
>from os.path import join
>
>def configuration(parent_package='',top_path=None):
> from numpy.distutils.misc_util import Configuration
> config = Configuration('random',parent_package,top_path)
>
> # Configure mtrand
> # Note that I'm mimicking the original behaviour of always using 'm' for
> # the math library. This should probably use the logic from numpy/core/setup.py
> # to chose the math libraries, but I'm going for minimal changes -- TAH
> if sys.platform == "win32":
> libraries = ['Advapi32']
> else:
> libraries = ['m']
> config.add_extension('mtrand',
> sources=[join('mtrand', x) for x in
> ['mtrand.c', 'randomkit.c', 'initarray.c',
> 'distributions.c']],
> libraries=libraries,
> depends = [join('mtrand','*.h'),
> join('mtrand','*.pyx'),
> join('mtrand','*.pxi'),
> ]
> )
>
> return config
>
>if __name__ == '__main__':
> from numpy.distutils.core import setup
> setup(**configuration(top_path='').todict())
>
>
|
|
From: Martin W. <mar...@gm...> - 2006-02-09 15:00:55
|
Found it (in the "old" docs). Must #define PY_ARRAY_UNIQUE_SYMBOL and call import_array (). Sorry to bother. Martin. On Thursday 09 February 2006 11:41, Martin Wiechert wrote: > Hi list, > > I'm trying to build an C extension, which uses arrays. It builds, and I can > import it from python, but the very first call to a numpy function > > ea = (PyObject *) PyArray_DescrFromType (PyArray_INT); > > gives me a segfault. > > I have absolutely no clue, but > > nm -l mymodule.so | grep rray > > gives > > 000026a0 b > PyArray_API > /usr/lib/python2.4/site-packages/numpy/core/include/numpy/__multiarray_api. >h:316 > > and this line reads > > static void **PyArray_API=NULL; > > which looks suspicious to me. Something wrong with my setup.py? > > Any suggestions? > > Regards, Martin. > > _______________________________________________ > SciPy-user mailing list > Sci...@sc... > http://www.scipy.net/mailman/listinfo/scipy-user |
|
From: Pau G. <pau...@gm...> - 2006-02-09 14:43:21
|
hi all,
i have a code the following code:
def foo(x):
'''takes a nd-array x and return another md-array'''
do something
return a md-array
A =3D an array of nd-arrays #A has 1+n dimensions
B =3D an array of md-arrays #B has 1+m dimensions
for i in len(A):
B[i] =3D foo(A[i])
and was wandering if there is an easy way to speed it up. I guess that
something using ufuncs could be used (?). Something like B =3D
ufunced_foo( A ).
thanks in advance,
pau
|
|
From: Alan G I. <ai...@am...> - 2006-02-09 14:38:47
|
On Thu, 9 Feb 2006, Bruce Southey apparently wrote: > The example of ndim to give the rank is not the same as the Matlab > function rank(a). See > http://en.wikipedia.org/wiki/Rank_of_a_matrix for definition of rank > that I would think that most people would use if they use Matlab Coming from GAUSS and having never studies tensors, I was also surprised by the 'rank' terminology. I believe this is why Travis changed to ndim, which is less likely to confuse users coming from a linear algebra perspective. Unfortunately the SciPy book currently uses the term 'rank' in the two conflicting ways. (It uses 'rank' in the linear algebra sense only in the discussion of lstsq on p.145.) It might be helpful for the tensor sense to always be qualified as 'tensor rank'? Cheers, Alan Isaac |
|
From: Bruce S. <bso...@gm...> - 2006-02-09 13:56:28
|
Hi, The example of ndim to give the rank is not the same as the Matlab function rank(a). See http://en.wikipedia.org/wiki/Rank_of_a_matrix for definition of rank that I would think that most people would use if they use Matlab and is provided by rank(a). I have not used the latest numpy but the equivalent function is not present in numarray/Numeric (to my knowledge) so you have to find some other way like using svd. Regards Bruce On 2/9/06, Bill Baxter <wb...@gm...> wrote: > I added some content to the "NumPy/SciPy for Matlab users" page on the sc= ipy wiki. > > But my knowledge of NumPy/SciPy isn't sufficient to fill in the whole cha= rt of equivalents that I laid out. > If folks who know both could browse by and maybe fill in a blank or two, = that would be great. I think this will be a helpful "getting started" page= for newbies to NumPy coming from matlab, like me. One of the most frustra= ting things is when you sit down and can't figure out how to do the most ba= sic things that do in your sleep in another environment (like making a colu= mn vector). So hopefully this page will help. > > The URL is : http://www.scipy.org/Wiki/NumPy_for_Matlab_Addicts > > Thanks, > Bill Baxter > |
|
From: Francesc A. <fa...@ca...> - 2006-02-09 12:49:59
|
A Dijous 09 Febrer 2006 06:36, Travis Oliphant va escriure:
> Travis Oliphant wrote:
> > I've started a branch on SVN to fix the unicode implementation in
> > NumPy so that internally all unicode arrays use UCS4. When a scalar
> > is obtained it will be the Python unicode scalar and the required
> > conversions (and data-copying) will be done.
> > If anybody would like to help the branch is
>
> Well, it turned out not to be too difficult. It is done.
Oh my! If I wouldn't have met you in person I would tend to think that
you are not human ;-)
> All Unicode
> arrays are now always 4-bytes-per character in NumPy. The length is
> specified in terms of characters (not bytes). This is different than
> other types, but it's consistent with the use of Unicode as characters.
Yes, I think this is a good idea.
> The array-scalar that a unicode array produces inherits directly from
> Python unicode type which has either 2 or 4 bytes depending on the build.
>
> On narrow builds where Python unicode is only 2-bytes, the 4-byte
> unicode is converted to 2-byte using surrogate pairs.
Very good!
> There may be lingering bugs of course, so please try it out and report
> problems.
Well, I've tried it for a while and it seems to me that you made a
very good job! Just a little thing:
# Using an UCS4 interpreter here
>>> len(buffer(numpy.array("qsds", 'U4')[()]))
16
>>> numpy.array("qsds", 'U4')[()].dtype
dtype('<U4')
>>> len(buffer(numpy.array("qsds", 'U3')[()]))
12
>>> numpy.array("qsds", 'U3')[()].dtype
dtype('<U3')
so far so good. But in UCS2 we have:
# Using an UCS2 interpreter here
>>> len(buffer(numpy.array("qsds", 'U4')[()]))
8 # Fine
>>> numpy.array("qsds", 'U4')[()].dtype
dtype('<U2') # Shouldn't be U4?
>>> len(buffer(numpy.array("qsds", 'U3')[()]))
6 # Fine
>>> numpy.array("qsds", 'U3')[()].dtype
dtype('<U1') # Shouldn't be U3?
I'll try to do more serious tests and contribute them back in a series
of test units.
=46inally, one final consideration. From a FAQ about Unicode
(http://www.cl.cam.ac.uk/~mgk25/unicode.html), one can read:
"""
No endianess is implied by the encoding names UCS-2, UCS-4, UTF-16,
and UTF-32, though ISO 10646-1 says that Bigendian should be preferred
unless otherwise agreed. It has become customary to append the letters
?BE? (Bigendian, high-byte first) and ?LE? (Littleendian, low-byte
first) to the encoding names in order to explicitly specify a byte
order.
"""
In NumPy, it seems that the endianess is the same of the platform,
while the ISO recomendation seems to say that Big-endian would be
preferred. I don't know which is the convention in Python about this,
but in any case, I'd follow Python convention, not the ISO one.
Cheers,
=2D-=20
>0,0< Francesc Altet =A0 =A0 http://www.carabos.com/
V V C=E1rabos Coop. V. =A0=A0Enjoy Data
"-"
|
|
From: Gary R. <gr...@bi...> - 2006-02-09 12:26:49
|
Vidar's documentation is under a GNU Free Documentation License. This is probably a problem with incorporating it directly into the scipy site, although Vidar was at one point happy to incorporate the MATLAB parts into Perry Greenfield and Robert Jedrzejewski's interactive data analysis tutorial. This tutorial used to be on the numarray page but has now disappeared and hasn't quite found it's way onto the scipy site, although it may just be due to a broken link. I've added a link to Vidar's site to the wiki. Gary R. Matthew Brett wrote: > Hi Bill, > > On 2/9/06, Bill Baxter <wb...@gm...> wrote: >> I added some content to the "NumPy/SciPy for Matlab users" page on the scipy >> wiki. > > Thanks a lot for doing this. Did you see this excellent reference? > Maybe it would be useful to combine effort in some way? > > http://www.37mm.no/matlab-python-xref.html > > Best, > > Matthew |
|
From: Darren D. <dd...@co...> - 2006-02-09 12:23:20
|
On Thursday 09 February 2006 7:03 am, Darren Dale wrote:
> I have a question about upcasting related to this example:
>
> a with elements less than 0.5 zeroed out:
> Matlab: a .* (a>0.5)
> NumPy: where(a<0.5, 0, a)
>
> I think numpy should be able to do a*a>0.5 as well, but instead one must
> do: a*(a>0.5).astype('i')
>
> Is it desireable to upcast bools in this case? I think so, one could always
> recover the current behavior by doing:
> (a*(a>0.5)).astype('?')
oops:
I should have been doing a*(a>0.5), the order of operations is important. My
mistake.
|
258 messages has been excluded from this view by a project administrator.