Re: propose deprecation of generalized-vector-*
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 pushed to wip-generalized-vectors. I'll merge this branch shortly, as there have been no objections. >> Maybe we should have scm_array_ref_1, scm_array_ref_2, etc. as it is >> done for some other functions taking rest lists. I can write a patch >> for that. > > 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 argument. A poor man's case-lambda... I have implemented this in stable-2.0. It should speed up array operations from Scheme significantly. Andy -- http://wingolog.org/
RTL Call Issue
Hello, I've hit an interesting issue in the RTL "call" instruction. I find that I can't execute a call instruction where the return frame starts at the same place that the procedure to call is at - it must start past there. That doesn't match my expected behavior, but I'm not sure if my expectations are wrong or there's really a bug. To see it, first define two procedures: (define (return-three) 3) (define (return-five) 5) To reproduce the behavior, try running this RTL program: ((assemble-program '(begin-program foo) (assert-nargs-ee/locals 2 3) (call 1 1 ()) (values) (values))) return-three return-five) I expected that to call return-five (which is at register 1) and then print the contents of its stack, which should contain 5. Instead, it gives an error. However, the following works: ((assemble-program '(begin-program foo) (assert-nargs-ee/locals 2 3) (call 2 1 ()) (values) (values))) return-three return-five) The only difference is in the call instruction - it pushes the new frame on just past the procedure, instead of on top of it. Is that expected? I first ran into this when I was cleaning up the CPS register allocator, and I could just change the register allocator, but I'm not sure if the problem is there or in the VM itself. Also note: the example used a procedure with two arguments that tried to call the second one. If you use a procedure with just one argument and try to call that, the VM will segfault. For example, ((assemble-program '((begin-program foo) (assert-nargs-ee/locals 1 3) (call 0 0 ()) (values) (values))) return-three) => segfault Thanks, Noah
Re: propose deprecation of generalized-vector-*
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 the index list comes up short it > makes a shared array with the remaining axes instead of giving a rank > error. So it shouldn't be any slower than array_ref. It could make sense, yes. What do others think? What happens for array-set!? Care to propose a patch? >> FWIW this is not the case. Vectors hold SCM objects, whereas uniform >> vectors hold unpacked machine values. > > Ok, I think I understand that. Still I don't see where the vref field > for the srfi4 types is set. The conversions seem to be done in > bytevector.c, can you point this out? Uniform vectors are just bytevectors. The only difference between the different kinds of uniform vectors is a "type" field indicating the "natural" type of the object. The type field is set when a bytevector is created, and is used in the generic array-ref functionality, and in the printer. One consequence is that you can (s8vector-ref #u8(#xff) 0) => -1. > I've also noticed > > 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 printer. Mark? :) > scheme@(guile-user)> (c64vector-ref #f64(1 2 3) 0) > $3 = 1.0+2.0i This is as expected. You are aliasing a double vector as a double complex vector. These are purely bit-level conversions, not type casting. Andy -- http://wingolog.org/
Re: propose deprecation of generalized-vector-*
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 very simply to do that. It accumulates on the > > position as it is done now, but if the index list comes up short it > > makes a shared array with the remaining axes instead of giving a rank > > error. So it shouldn't be any slower than array_ref. > > It could make sense, yes. What do others think? What happens for > array-set!? Care to propose a patch? 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. It breaks the expectation that array-ref always returns an element of the array. It seems to be that it might be better to have some other function that returns a slice of the array, with a one-element array being a special case of its result. (array-ref could even be implemented in terms of this other function.) I think that returning a slice instead of throwing an error would be natural if we automatically mapped scalar operations over arrays. But we don't, so an array really does have to be viewed as a very different type than its components, so this change doesn't make sense to me. I would be happy to be wrong here, but this just jumped out at me as something that would be a surprising change in behavior, and possibly lead to bugs. Does anyone have example code that shows why this makes sense? Best, Noah
Re: propose deprecation of generalized-vector-*
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 on the >>> position as it is done now, but if the index list comes up short it >>> makes a shared array with the remaining axes instead of giving a rank >>> error. So it shouldn't be any slower than array_ref. >> >>It could make sense, yes. What do others think? What happens for >>array-set!? Care to propose a patch? > > > 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 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]] (array-ref np 1 1) -> 5 (array-ref np 1 :) -> [4, 5, 6] (array-ref np : 1) -> [[2], [5], [8]] Or maybe that's already in Scheme. I'll admit I've never done matrices in scheme. -Mike
Re: propose deprecation of generalized-vector-*
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 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]] > (array-ref np 1 1) -> 5 > (array-ref np 1 :) -> [4, 5, 6] > (array-ref np : 1) -> [[2], [5], [8]] > Yes, that would be cool. But I'm not arguing that we shouldn't have some cool array-slicing functions - I'm just saying that they might belong in a separate function, not in array-ref. > Or maybe that's already in Scheme. I'll admit I've never done matrices > in scheme. > As far as I know, there's no standard Scheme way to do arrays. I haven't done arrays or matrices in Scheme either, so don't take what I say too seriously. I would like to do it some time, but it'll probably only happen if I need to do a lot of array programming for work some time. I think the only way to get the interface right is to have someone write some serious array-processing software in Guile, and then basically do whatever they say. :-) Noah
Re: propose deprecation of generalized-vector-*
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, in mathlab and octave indices [are not offset] start from 1 to N do we actually have a matrice calculus [offset based the better] lib or binding or scheme package ? any pointer is welcome David
Re: propose deprecation of generalized-vector-*
> 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 again. It hasn't run since, the 1.6 days, I think. -Mike
Precedence for reader extensions
I'm working on an mit-scheme compatibility module (compat mit-scheme) enabling Guile to read a (so far) subset of mit-scheme code. Now I have the problem that mit-scheme has the two constants #!optional and #!rest (mit-scheme extensions to the scheme standard). I thought that I could support this using %read-hash-procedures but discovered that there are three "precedence levels": 1. Most predefine hash syntax like #(, #! etc. 2. %read-hash-procedures 3. #| This means that I can't add new syntax for #!. I propose to simplify this to only two levels: 1. %read-hash-procedures 2. predefined syntax This would be conceptually simpler and more flexible. It could also be used to support mit-scheme read syntax. If we do not implement this change, I need to use Ludovic's (nice) guile-reader. But that package contains C code meaning that (compat mit-scheme) can't be distributed using guilehall. In any case, I think it would be good to be able to support other Scheme's read syntax using the standard reader. If anyone is afraid about the effect this would have on reader performance, it is possible to compile %read-hash-procedures to a table of flags indicating exceptions. Opinions? Best regards, Mikael
Re: Precedence for reader extensions
On Mon, Feb 18, 2013 at 10:05 PM, Mikael Djurfeldt wrote: > guilehall guildhall (I write too fast)
Re: Precedence for reader extensions
On Mon, Feb 18, 2013 at 10:05 PM, Mikael Djurfeldt wrote: > If anyone is afraid about the effect this would have on reader > performance, it is possible to compile %read-hash-procedures to a > table of flags indicating exceptions. But, given the current interface to reader extensions in the form of an alist in a fluid, such a table would have to be compiled at each entry to "read"...
Re: Precedence for reader extensions
(Sorry for thinking publicly.) The reason why I don't simply use guile-reader but start bugging you about it is that it feels silly that Guile, which was originally supposed to be able to support different languages, can't even support the read syntax of a sibling scheme interpreter. It is somewhat inflexible. What about including Ludovic's guile-reader as a library in the main guile distribution?
Problems with 'number->string' (was Re: propose deprecation of generalized-vector-*)
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 > printer. Mark? :) Yes, our number printer is seriously flawed and needs a rewrite. It prints subnormal[1] floats as "#.#", and even in typical cases often fails to print enough digits to get the same number back when you read it back in. Note that this also affects compiled code involving numbers, because the compiler serializes numbers using 'number->string'. For example, (* 1e-155 1e-155) returns #f at the REPL, because peval turns this into a constant which happens to be a subnormal. During assembly it serializes this to "#.#", and then 'string->number' returns #f. Also, 3.14159265358979323846264338327950288419716939937510582097494, if compiled, fails to produce the float closest to pi. (acos -1) works properly, but only because this expression is not currently folded to a constant by the compiler. I've already started work on this (based on "Printing Floating-Point Numbers Quickly and Accurately" by Burger and Dybvig) but got distracted. Mark [1] http://en.wikipedia.org/wiki/Subnormal_number
Re: Precedence for reader extensions
Hi Mikael, Mikael Djurfeldt writes: > I'm working on an mit-scheme compatibility module (compat mit-scheme) > enabling Guile to read a (so far) subset of mit-scheme code. > > Now I have the problem that mit-scheme has the two constants > #!optional and #!rest (mit-scheme extensions to the scheme standard). > > I thought that I could support this using %read-hash-procedures but > discovered that there are three "precedence levels": > > 1. Most predefine hash syntax like #(, #! etc. > 2. %read-hash-procedures > 3. #| > > This means that I can't add new syntax for #!. > > I propose to simplify this to only two levels: > > 1. %read-hash-procedures > 2. predefined syntax I don't think this would be sufficient. The problem is that tokens of the form "#!" have become standardized. To name a few examples, both R6RS and R7RS define the reader directives #!fold-case and #!no-fold-case, R6RS has #!r6rs, and SRFI-105 has #!curly-infix. Guile also has #! ... !# block comments to help with the handling of executable scripts. One idea would be to provide a way to register new handlers for tokens of the form "#!". However, we'd probably want to discourage its use, because every time you add a new token, you potentially turn existing #! ... !# block comments into lexical errors. Thanks for working on scmutils for Guile! I've been wanting this for a while :) Mark
Re: propose deprecation of generalized-vector-*
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-ref can be extended very simply to do that. It accumulates on the position as it is done now, but if the index list comes up short it makes a shared array with the remaining axes instead of giving a rank error. So it shouldn't be any slower than array_ref. >>> >>>It could make sense, yes. What do others think? What happens for >>>array-set!? Care to propose a patch? >> >> >> 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. Right, these are my sentiments also (including the snipped part). Relaxing array-ref in the proposed way means it could hide programming errors, etc. Particularly with typed arrays, where previously the result will reliably be of the given type. > > 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]] > (array-ref np 1 1) -> 5 > (array-ref np 1 :) -> [4, 5, 6] > (array-ref np : 1) -> [[2], [5], [8]] > > Or maybe that's already in Scheme. I'll admit I've never done matrices > in scheme. Yes, but please lets imagine this only and not multiply the purpose of array-ref. Other languages do that kind of thing a lot with a sort of “guess what I really meant to do and do that instead”, which leads to messy documentation, programming errors, and security issues (Ruby-on-Rails?). This is certainly a common enough usage of make-shared-array to justify its own procedure with more helpful syntax. Even I would make this two procedures, array-slice and array-slice/shared, to decide between new or shared array. Regards
Re: [Potluck] a lightweight web framework
Hey guys! Now it's the time to officially release my potluck dish: https://github.com/NalaGinrut/artanis Let me re-introduce it: * just read the README on the link I gave ;-P Happy hacking! Enjoy!
