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 wo
Hello again,
On Fri, Mar 1, 2013 at 4:01 AM, Daniel Llorens wrote:
> > 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 you about array-ref,
> b
On Fri 01 Mar 2013 10:01, Daniel Llorens 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 I'd like from Guile
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
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 b
Hello,
On Thu, Feb 28, 2013 at 2:10 PM, Daniel Llorens
wrote:
>
> 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 als
If guile introduces full-fledged support of arrays for numeric
computing, and for communicating with external libraries, such as the
currently-moribund Guile-numerics interface to GNU Scientific Library
(GSL), libsndfile, FFTW, and LAPACK
http://www.nongnu.org/guile-num/
please do not for
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, ord
Hello,
On Wed, Feb 20, 2013 at 8:13 PM, Daniel Llorens
wrote:
>
> 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 duplicatin
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
opt
On 19 February 2013 00:25, Mike Gran wrote:
> From: Noah Lavine
>>Hello,
>>>On Wed 23 Jan 2013 13:20, Daniel Llorens 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-re
Andy Wingo writes:
> On Wed 23 Jan 2013 13:20, Daniel Llorens 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 like a bug in our number
> printe
> From: David Pirotte
> 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 to run aga
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
On Mon, Feb 18, 2013 at 11:25 AM, Mike Gran wrote:
> From: Noah Lavine
> > 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 array-ref has to have
> the same numb
From: Noah Lavine
>Hello,
>>On Wed 23 Jan 2013 13:20, Daniel Llorens 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 o
Hello,
On Mon, Feb 18, 2013 at 10:55 AM, Andy Wingo wrote:
> Hi,
>
> On Wed 23 Jan 2013 13:20, Daniel Llorens
> 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
Hi,
On Wed 23 Jan 2013 13:20, Daniel Llorens 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 done now, but if
Hi Daniel,
On Wed 23 Jan 2013 10:06, Andy Wingo writes:
> On Tue 22 Jan 2013 15:31, Daniel Llorens 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
Hi!
Andy Wingo 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
> accessed with
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
Hi,
On Wed 23 Jan 2013 00:27, Daniel Llorens 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 I would also
want it ov
On Tue 22 Jan 2013 15:31, Daniel Llorens 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 should have scm_array
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
Hi Daniel,
Thanks for thinking about this.
On Tue 22 Jan 2013 19:31, Daniel Llorens writes:
>> I think this is fair for type polymorphism. It makes sense to let
>> vector- work on uniform vectors because the implementation should be
>> identical.
>>
>> It's different for arrays because even fo
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 vec
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.
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 interfa
Hi,
Daniel Llorens 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
>
> 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 th
Hi!
Daniel Llorens 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, which also
> work
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
> To: guile-devel@gnu.org
> Subject: Re: propose deprecation of generalized-vector-*
...
> It seems to me that array-length should return the
Daniel Llorens 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 (array-dimensions a))
>
> or maybe
33 matches
Mail list logo
