Re-introducing myself + blog link (GSOC)
2014-04-23 21:34:43 GMT
icc -c -I/work/apps/matlab/2013a/extern/include -I/work/apps/matlab/2013a/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fexceptions -fPIC -fno-omit-frame-pointer -pthread -DMX_COMPAT_64 -O -DNDEBUG "matrixMultiply.c"
I wish to eventually achieve all the above functionality for the Octave code as well. I thought of trying first with MATLAB as I thought the interface and support for external library support is better with it. Please do let me know your suggestions. Thanks.
Is it time to build Octave with OpenMP by default? It looks to me like it's been an "experimental" disabled-by-default option since the 3.4.0 release. It has been enabled in Debian and Ubuntu builds since 3.4.3 was released in late 2011 and I'm not aware of any negative consequences. Autoconf now provides a AC_OPENMP macro with a --disable-openmp option, we could use this to handle setting up OpenMP to be consistent with other projects. See bug #41699  for my motivation for enabling OpenMP by default (segfault when exiting or unloading oct-files that use OpenMP). Also there might be extra steps needed to build with OpenMP using MXE, have any MXE builders looked into it?  https://savannah.gnu.org/bugs/?41699 Thanks, -- -- mike
Dear all, thanks for accepting my proposal for this year Google Summer of Code. I am looking forward to working on it, so I would be glad to hear your suggestions about what to study to be perfectly ready on the “D-Day”. I think I should read the whole documentation of last year work as a starting point, then probably get a deep understanding of the interface between Octave and FEniCS. Probably Marco can give me some good hints about this and provide useful advice on anything important I did not mention. Kind regards, Eugenio
Hello At configure script checking llvm, existing of TargetData.h is necessary. However, llvm 3.2 or later, there seems not TargetData.h in include/llvm/Target directory. Is configure check TargetData.h in llvm obsolate? Regards Tatsuro
Hi, I've been tinkering with making a symbolic package using the Python CAS SymPy. The goal is feature parity with other symbolic packages. You can try it now, either git clone, or just download a .zip file (which works as a GNU Octave package). https://github.com/cbm755/octsympy Here's some examples: > pkg install octsympy-master.zip > pkg load octsympy > syms x y z a b c k > A = [sin(x/2) floor(exp(x*c)); ... acosh(x^(b*c)/pi) ceil(sin(x/gamma(x)))] > pretty(A) > > f = exp(-x^2); > F = fourier(f,x,k); > pretty(F) > g = ifourier(F,k,x); > simplify(f - g) > > limit(1/x, x, 0, 'left') If you have problems with the Python communication (I've only tested on GNU/Linux and my guess is it doesn't work out-of-box on Windows), try: > octsympy_config ipc_system I'd be happy to move everything elsewhere at some point, but for now, issue tracker is also at GitHub, so please give it a try and file some bugs Help also very much appreciated! best, Colin -- -- Colin Macdonald University Lecturer in Numerical Methodologies Tutorial Fellow at Oriel College University of Oxford
While looking at some problems with printing 64-bit integer values with printf, I found that Matlab's printf function silently switches from integer formats like '%d' or '%u' to '%e' when values are not integers or when they exceed the maximum value possible for a 64-bit integer type. Matlab also seems to be ignoring size specifications for integer formats, so although formats like '%hd' (short int) are accepted, there seems to be no change in output compared to just using '%d'. And '%d' always handles up to 64-bit integers without needing 'l' or 'll'. I checked in the following change on the default branch: http://hg.savannah.gnu.org/hgweb/octave/rev/491b0adfec95 Now you can expect behavior like the following, which appears to be compatible with Matlab: sprintf('%d',intmin('int32')) %% ans = -2147483648 sprintf('%d',intmax('int32')) %% ans = 2147483647 sprintf('%d',intmin('int64')) %% ans = -9223372036854775808 sprintf('%d',intmax('int64')) %% ans = 9223372036854775807 sprintf('%d',intmin('uint32')) %% ans = 0 sprintf('%d',intmax('uint32')) %% ans = 4294967295 sprintf('%d',intmin('uint64')) %% ans = 0 sprintf('%d',intmax('uint64')) %% ans = 1.84467e+19 sprintf('%d',realmin('single')) %% ans = 1.17549e-38 sprintf('%d',realmax('single')) %% ans = 3.40282e+38 sprintf('%d',realmin('double')) %% ans = 2.22507e-308 sprintf('%d',realmax('double')) %% ans = 1.79769e+308 There is still one difference: Matlab switches to '%e' and Octave is currently switching to '%g'. Should we follow Matlab exactly here? I generally prefer '%g' over '%e' because it seems easier to me to read numbers without unnecessary e+04 style exponents appended. This change caused a few new test failures in cases where '%d' was previously assumed to always produce an integer result. I fixed one problem in the datestr function by rounding the printf argument that was used with a '%d' format. I could use some help fixing the stemleaf function since I'm not sure what the intent is there. jwe