Re: propose deprecation of generalized-vector-*

2013-03-04 Thread Aharon Robbins
Hello All. Nelson wrote: If guile introduces full-fledged support of arrays for numeric computing, and for communicating with external libraries, About which I don't have much comment. He then wrote: The GNU gawk developers are currently working on similar extensions to the code world

Re: propose deprecation of generalized-vector-*

2013-03-03 Thread Noah Lavine
Hello again, On Fri, Mar 1, 2013 at 4:01 AM, Daniel Llorens daniel.llor...@bluewin.chwrote: think this comes down to a more fundamental difference - I still don't think that functions should automatically map over arrays, and you do. If they did automatically map, then I would agree with

Re: propose deprecation of generalized-vector-*

2013-03-01 Thread Daniel Llorens
On Mar 1, 2013, at 03:42, Noah Lavine wrote: There should still be an operator that splits in other ways, but I agree that we can shortcut that in many cases. One think I like about the frame / cell split is that you know that the result will have the same frame. So I imagine an operator

Re: propose deprecation of generalized-vector-*

2013-03-01 Thread Andy Wingo
On Fri 01 Mar 2013 10:01, Daniel Llorens daniel.llor...@bluewin.ch writes: scheme@(guile-user) ,optimize (vector-ref #(1 2 3) 0) $1 = 1 scheme@(guile-user) ,optimize (array-ref #(1 2 3) 0) $2 = (array-ref '#(1 2 3) 0) File a bug for this case, this sort of thing is totally fixable :) What

Re: propose deprecation of generalized-vector-*

2013-02-28 Thread Daniel Llorens
On Feb 22, 2013, at 01:22, Noah Lavine wrote: I agree about the speed issue, but I hope it will get better soon. The RTL VM will fix some of it, and native compilation will fix more. That's on Scheme, but there are also many optimization issues related to array operations. Temporaries,

Re: propose deprecation of generalized-vector-*

2013-02-28 Thread Noah Lavine
Hello, On Thu, Feb 28, 2013 at 2:10 PM, Daniel Llorens daniel.llor...@bluewin.chwrote: On Feb 22, 2013, at 01:22, Noah Lavine wrote: I agree about the speed issue, but I hope it will get better soon. The RTL VM will fix some of it, and native compilation will fix more. That's on Scheme,

Re: propose deprecation of generalized-vector-*

2013-02-28 Thread Noah Lavine
After reading through my email, I realize that I left out the most important part - a reason *why* functions shouldn't map over arrays. My reason is that this makes function application a more complicated process. Right now, functions are very simple things in Scheme. If we add automatic mapping

Re: propose deprecation of generalized-vector-*

2013-02-21 Thread Noah Lavine
Hello, On Wed, Feb 20, 2013 at 8:13 PM, Daniel Llorens daniel.llor...@bluewin.chwrote: On Feb 18, 2013, at 16:55, Andy Wingo wrote: It could make sense, yes. What do others think? What happens for array-set!? Care to propose a patch? Patch is attached. It looks a bit unwieldy

Re: propose deprecation of generalized-vector-*

2013-02-20 Thread Daniel Llorens
On Feb 18, 2013, at 16:55, Andy Wingo wrote: It could make sense, yes. What do others think? What happens for array-set!? Care to propose a patch? Patch is attached. It looks a bit unwieldy because I am duplicating scm_array_handle_pos(), and I also had to fix the recent array_ref_1

Re: propose deprecation of generalized-vector-*

2013-02-18 Thread Andy Wingo
Hi Daniel, On Wed 23 Jan 2013 10:06, Andy Wingo wi...@pobox.com writes: On Tue 22 Jan 2013 15:31, Daniel Llorens daniel.llor...@bluewin.ch writes: On Jan 21, 2013, at 17:11, Andy Wingo wrote: The patch attached applies over yours and is to document this function and a couple others in the

Re: propose deprecation of generalized-vector-*

2013-02-18 Thread Andy Wingo
Hi, On Wed 23 Jan 2013 13:20, Daniel Llorens daniel.llor...@bluewin.ch writes: In [2]: a = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]]) In [4]: a[1] Out[4]: array([4, 5, 6]) In [5]: a[1, 1] Out[5]: 5 array-ref can be extended very simply to do that. It accumulates on the position as it is

Re: propose deprecation of generalized-vector-*

2013-02-18 Thread Mike Gran
From: Noah Lavine noah.b.lav...@gmail.com Hello, On Wed 23 Jan 2013 13:20, Daniel Llorens daniel.llor...@bluewin.ch writes: In [2]: a = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]]) In [4]: a[1] Out[4]: array([4, 5, 6]) In [5]: a[1, 1] Out[5]: 5 array-ref can be extended very simply to do

Re: propose deprecation of generalized-vector-*

2013-02-18 Thread Noah Lavine
On Mon, Feb 18, 2013 at 11:25 AM, Mike Gran spk...@yahoo.com wrote: From: Noah Lavine noah.b.lav...@gmail.com I haven't worked with the array functionality, so I might be missing something, but I don't see why this is natural for array-ref. One could imagine a Matlab-like syntax where

Re: propose deprecation of generalized-vector-*

2013-02-18 Thread David Pirotte
Heya, One could imagine a Matlab-like syntax where array-ref has to have the same number of indices as the underlying array, but, if an index were replaced with a symbol, it would return a slice. if np is [[1, 2, 3], [4, 5, 6], [7, 8, 9]] just in case it would [one day] matter,

Re: propose deprecation of generalized-vector-*

2013-02-18 Thread Mike Gran
From: David Pirotte da...@altosw.be do we actually have a matrice calculus [offset based the better] lib or binding or scheme package ? any pointer is welcome There once was a package called guile-num. You can find it here. www.nongnu.org/guile-num But, it would take some work to get it

Problems with 'number-string' (was Re: propose deprecation of generalized-vector-*)

2013-02-18 Thread Mark H Weaver
Andy Wingo wi...@pobox.com writes: On Wed 23 Jan 2013 13:20, Daniel Llorens daniel.llor...@bluewin.ch writes: scheme@(guile-user) (f64vector-ref #s64(1 2 3) 0) $1 = #.# Here you are interpreting an int64 as a double, which should work, but this printed result is really bizarre and looks

Re: propose deprecation of generalized-vector-*

2013-02-18 Thread Daniel Hartwig
On 19 February 2013 00:25, Mike Gran spk...@yahoo.com wrote: From: Noah Lavine noah.b.lav...@gmail.com Hello, On Wed 23 Jan 2013 13:20, Daniel Llorens daniel.llor...@bluewin.ch writes: In [2]: a = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]]) In [4]: a[1] Out[4]: array([4, 5, 6]) In [5]: a[1,

Re: propose deprecation of generalized-vector-*

2013-01-23 Thread Andy Wingo
On Tue 22 Jan 2013 15:31, Daniel Llorens daniel.llor...@bluewin.ch writes: On Jan 21, 2013, at 17:11, Andy Wingo wrote: The patch attached applies over yours and is to document this function and a couple others in the manual. Thanks, applied and pushed to wip-generalized-vectors. Maybe we

Re: propose deprecation of generalized-vector-*

2013-01-23 Thread Andy Wingo
Hi, On Wed 23 Jan 2013 00:27, Daniel Llorens daniel.llor...@bluewin.ch writes: I guess I don't value that much having a specific interface just for rank 1 objects. I don't care much either; I don't think I have ever used the generalized vector routines. If I wanted real polymorphism, I think

Re: propose deprecation of generalized-vector-*

2013-01-23 Thread Daniel Llorens
On Jan 23, 2013, at 10:06, Andy Wingo wrote: For C, that makes sense. Something should be done for Scheme as well, but it's not terribly urgent. Perhaps make scm_array_ref not be bound to array-ref, and instead bind array-ref to some function that takes two optional arguments and a rest

Re: propose deprecation of generalized-vector-*

2013-01-23 Thread Ludovic Courtès
Hi! Andy Wingo wi...@pobox.com skribis: What is a vector? Possible answers: 1. A vector is something that answers #t to vector?, which contains some number of storage slots accessible in a mostly-O(1) way, the number of slots is given by vector-length, and the slots can be

Re: propose deprecation of generalized-vector-*

2013-01-22 Thread Daniel Llorens
On Jan 21, 2013, at 17:11, Andy Wingo wrote: Hi, Sorry for the long delay. Deprecating the generalized-vector functions sounds mostly sensible to me, and the proposed semantics of array-length sound fine. Attached is a first patch in that direction. The changes look good to me. The

Re: propose deprecation of generalized-vector-*

2013-01-22 Thread Daniel Llorens
On Jan 22, 2013, at 15:31, Daniel Llorens wrote: On Jan 21, 2013, at 17:11, Andy Wingo wrote: I always wondered why vector-ref and vector-set! didn't do what generalized-vector-ref and generalized-vector-set! did. I mean, they are primitive generics. Might it make sense to allow

Re: propose deprecation of generalized-vector-*

2013-01-22 Thread Daniel Llorens
On Jan 22, 2013, at 21:52, Andy Wingo wrote: Hello, Handling stride and bounds is not a problem. The generic array handle interface lets us do this in a straightforward way. Certainly, but in this case, a vector is just an array of rank 1. I guess I don't value that much having a specific

Re: propose deprecation of generalized-vector-*

2013-01-21 Thread Andy Wingo
Hi, Sorry for the long delay. Deprecating the generalized-vector functions sounds mostly sensible to me, and the proposed semantics of array-length sound fine. Attached is a first patch in that direction. However, before going further, some thoughts. Firstly, array-set! has a different

Re: propose deprecation of generalized-vector-*

2012-11-03 Thread Daniel Llorens
5. Re: propose deprecation of generalized-vector-* (Ludovic =?utf-8?Q?Court=C3=A8s?=) Yes. That procedure would only make sense for one-dimensional arrays anyway. It could just as well throw an error when passed a multi-dimensional array, no? I think that there should

Re: propose deprecation of generalized-vector-*

2012-11-03 Thread Ludovic Courtès
Hi, Daniel Llorens daniel.llor...@bluewin.ch skribis: 5. Re: propose deprecation of generalized-vector-* (Ludovic =?utf-8?Q?Court=C3=A8s?=) Yes. That procedure would only make sense for one-dimensional arrays anyway. It could just as well throw an error when passed a multi

Re: propose deprecation of generalized-vector-*

2012-11-02 Thread Ludovic Courtès
Hi! Daniel Llorens daniel.llor...@bluewin.ch skribis: today I filed a bug on generalized-vector-list http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12465 I remember similar bugs in the past, and I'm thinking that these functions are redundant since we have array-ref, array-list, and so on,

Re: propose deprecation of generalized-vector-*

2012-09-19 Thread Peter TB Brett
Daniel Llorens daniel.llor...@bluewin.ch writes: The only generalized-vector-? function that doesn't have a direct array-? correspondence is generalized-vector-length. However, even for arrays of rank 1 it is often convenient to have a function such as (array-length a) = (car

Re: propose deprecation of generalized-vector-*

2012-09-19 Thread Daniel Llorens
On Sep 19, 2012, at 18:00, guile-devel-requ...@gnu.org wrote: Date: Wed, 19 Sep 2012 13:02:25 +0100 From: Peter TB Brett pe...@peter-b.co.uk To: guile-devel@gnu.org Subject: Re: propose deprecation of generalized-vector-* ... It seems to me that array-length should return the first non

propose deprecation of generalized-vector-*

2012-09-18 Thread Daniel Llorens
Hello, today I filed a bug on generalized-vector-list http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12465 I remember similar bugs in the past, and I'm thinking that these functions are redundant since we have array-ref, array-list, and so on, which also work on strings, uniform vectors, etc.