Menu
▾
▴
nlisp-developer — Discussion of development of NLISP, subversion change logs
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(13) |
Oct
(5) |
Nov
(3) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(5) |
Feb
(21) |
Mar
(6) |
Apr
(9) |
May
(2) |
Jun
(9) |
Jul
(4) |
Aug
(9) |
Sep
(4) |
Oct
(18) |
Nov
(13) |
Dec
(1) |
| 2008 |
Jan
(5) |
Feb
(2) |
Mar
(2) |
Apr
|
May
(21) |
Jun
|
Jul
(1) |
Aug
|
Sep
(4) |
Oct
(9) |
Nov
(5) |
Dec
(20) |
| 2009 |
Jan
(72) |
Feb
(37) |
Mar
(3) |
Apr
(3) |
May
(1) |
Jun
|
Jul
(4) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <lei...@us...> - 2014-06-25 16:12:34
|
Revision: 196
http://sourceforge.net/p/nlisp/code/196
Author: leighsmith
Date: 2014-06-25 16:12:24 +0000 (Wed, 25 Jun 2014)
Log Message:
-----------
Added exports, minimisation package, improved transpose
Modified Paths:
--------------
trunk/gsl.swig
trunk/nlisp-core.lisp
trunk/nlisp.asd
trunk/package.lisp
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: Mirko V. <mir...@gm...> - 2009-08-03 01:00:03
|
Hello, I have been staring at nlisp-gnuplot, and think that it may benefit from some cleanup (such as converting some of the `if' tests to `when', where appropriately), but more importantly, refactoring the code. This is what I had in mind: Break up the file into (at least) three modules: 1. gnuplot-interface 2. common lisp add-ons 3. nlisp-add-ons The first one would establish the link to gnuplot, and as direct-as-possible interface to its commands. For example, its plot command would only send gnuplot's plot command, with minimum arguments. It would accept only basic lisp data objects (lists and vectors & arrays) for plotting. (Regarding plot, I would like it to offer several data input methods, such as the current binary file one, but also ascii files and the plot -,- ... data list. The major reason is philosophical -- forcing the gnuplot:plot to accept multiple formats will force us/me to think harder and write better code.) The second module would add lispiness to the interface. It would provide `with-window' and `do-windows' type features. This second one should be somewhat independent of gnuplot, in the sense that similar commands should work with other plotting tools as they become available. The final one has two purposes: - send nlisp datatypes to gnuplot. - preserve the current nlisp syntax, so as not to break backward compatibility. This module would be done done on a general basis so that it can serve as a template for other packages such as gsll. If done properly, the refactoring would provide a useful code base for projects other than nlisp. Initially, it would steal quite a bit from nlisp-gnuplot (which is currently copyrighted to Dave, and would need permission from him). Your thoughts? In particular, if this proceeds, we want a good test suite. Cheers, Mirko |
|
From: Leigh S. <le...@le...> - 2009-07-16 17:34:12
|
(defun set-image-dimensions (image-size image-origin) (plot-command "set size ~f,~f" (first image-size) (second image- size)) (plot-command "set origin ~f,~f" (first image-origin) (second image- origin))) (set-image-dimensions '((1.0 0.5) (0.0 0.5))) (image x :reset nil) (set-image-dimesions '((1.0 0.5) (0.0 0.0))) (plot y x :reset nil) (reset-plot) On 16/07/2009, at 3:22 PM, Mirko Vukovic wrote: > Great, > > Can you provide a code snippet regarding `you need to specify > different windows within your multiplot' below? It is no huge rush - > i.e., when your work takes you close to some useful example > > Thanks > Leigh -- Leigh M. Smith mailto:le...@le... http://www.leighsmith.com skype:aussieleighsmith |
|
From: Mirko V. <mir...@gm...> - 2009-07-16 13:22:21
|
Great, Can you provide a code snippet regarding `you need to specify different windows within your multiplot' below? It is no huge rush - i.e., when your work takes you close to some useful example Thanks On Wed, Jul 15, 2009 at 3:16 PM, Leigh Smith<le...@le...> wrote: > Yes I do many multiplots within NLISP. > > The trick is the plot :reset nil keyword parameter to allow sending other > (plot-command)'s. > > I do: > > (window) > (plot-command "set multiplot") > > (plot y x :reset nil) ; etc > ; you need to specify different windows within your multiplot *** code snippet needed here ! > (plot y x :reset nil) ; etc > > (plot-command "unset multiplot") > (reset-plot) > (close-window)) > > > > On 15/07/2009, at 5:33 PM, Mirko Vukovic wrote: > >> Has anyone been succesfull in producing multiple plots such as shown here: >> >> http://nucl.sci.hokudai.ac.jp/~ohnishi/Lib/gnuplot.html (scroll >> towards the bottom of the page). >> >> I tried to replicate that example, but I get the feel that nlisp's >> plot command does a lot of internal set-up that counteracts the plot >> commands. >> >> Thanks >> >> Mirko >> >> >> ------------------------------------------------------------------------------ >> Enter the BlackBerry Developer Challenge >> This is your chance to win up to $100,000 in prizes! For a limited time, >> vendors submitting new applications to BlackBerry App World(TM) will have >> the opportunity to enter the BlackBerry Developer Challenge. See full >> prize >> details at: http://p.sf.net/sfu/Challenge >> _______________________________________________ >> Nlisp-developer mailing list >> Nli...@li... >> https://lists.sourceforge.net/lists/listinfo/nlisp-developer > > Leigh > -- > Leigh M. Smith > mailto:le...@le... > http://www.leighsmith.com > skype:aussieleighsmith > > |
|
From: Leigh S. <le...@le...> - 2009-07-16 12:14:38
|
Yes I do many multiplots within NLISP. The trick is the plot :reset nil keyword parameter to allow sending other (plot-command)'s. I do: (window) (plot-command "set multiplot") (plot y x :reset nil) ; etc ; you need to specify different windows within your multiplot (plot y x :reset nil) ; etc (plot-command "unset multiplot") (reset-plot) (close-window)) On 15/07/2009, at 5:33 PM, Mirko Vukovic wrote: > Has anyone been succesfull in producing multiple plots such as shown > here: > > http://nucl.sci.hokudai.ac.jp/~ohnishi/Lib/gnuplot.html (scroll > towards the bottom of the page). > > I tried to replicate that example, but I get the feel that nlisp's > plot command does a lot of internal set-up that counteracts the plot > commands. > > Thanks > > Mirko > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited > time, > vendors submitting new applications to BlackBerry App World(TM) will > have > the opportunity to enter the BlackBerry Developer Challenge. See > full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Nlisp-developer mailing list > Nli...@li... > https://lists.sourceforge.net/lists/listinfo/nlisp-developer Leigh -- Leigh M. Smith mailto:le...@le... http://www.leighsmith.com skype:aussieleighsmith |
|
From: Mirko V. <mir...@gm...> - 2009-07-15 15:33:23
|
Has anyone been succesfull in producing multiple plots such as shown here: http://nucl.sci.hokudai.ac.jp/~ohnishi/Lib/gnuplot.html (scroll towards the bottom of the page). I tried to replicate that example, but I get the feel that nlisp's plot command does a lot of internal set-up that counteracts the plot commands. Thanks Mirko |
|
From: <lei...@us...> - 2009-05-26 09:24:00
|
Revision: 195
http://nlisp.svn.sourceforge.net/nlisp/?rev=195&view=rev
Author: leighsmith
Date: 2009-05-26 09:23:51 +0000 (Tue, 26 May 2009)
Log Message:
-----------
Added .iseq-incr macro to iterate with an increment parameter. Added .mult. Added
loading of nlisp-gsll-compat source. Added routines to improve array printing.
Modified Paths:
--------------
trunk/nlisp-array-creation.lisp
trunk/nlisp-class.lisp
trunk/nlisp-core.lisp
trunk/nlisp.asd
trunk/package.lisp
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <lei...@us...> - 2009-04-20 13:59:09
|
Revision: 194
http://nlisp.svn.sourceforge.net/nlisp/?rev=194&view=rev
Author: leighsmith
Date: 2009-04-20 13:34:14 +0000 (Mon, 20 Apr 2009)
Log Message:
-----------
Corrected let* typo.
Modified Paths:
--------------
trunk/nlisp-gnuplot.lisp
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <lei...@us...> - 2009-04-20 13:28:17
|
Revision: 193
http://nlisp.svn.sourceforge.net/nlisp/?rev=193&view=rev
Author: leighsmith
Date: 2009-04-20 13:28:14 +0000 (Mon, 20 Apr 2009)
Log Message:
-----------
Made plotting more robust when the gsl viewer closes. Exported .vectorp and plotting
functions close-window and close-windows. Added nlisp-gsll-compat.lisp building into
ASDF. Now handles making zero element arrays intelligently.
Modified Paths:
--------------
trunk/nlisp-array-creation.lisp
trunk/nlisp-array-indexing.lisp
trunk/nlisp-core.lisp
trunk/nlisp-gnuplot.lisp
trunk/nlisp-gsll-compat.lisp
trunk/nlisp.asd
trunk/package.lisp
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: Mirko V. <mir...@gm...> - 2009-04-10 14:17:26
|
Hello, I am running some wave propagation simulations, and would like to create an animation of the results. I want to animate two types of results: 1) a simple x-y plot that shows the wave profile at some instance in time. I would like to save a sequence of these plots and then animate them. 2) an image plot that shows the intensity map of a wave over a region. Again, save a sequence of those and animate them. I am assuming that if I set the output to a gif file, and save a bunch of those, I can view the gifs using some animation tools (of course, I would need to set the plot parameters, such as (color)scale, so that these don't vary from frame to frame. Can you guys have any recommendations, experience, etc, before I go off and re-invent the wheel? Infuriatingly enough, about two weeks ago, in gnuplot's info I stumbled across a gnuplot output device that could pipe its output to a unix utility. Execution of successive plot commands would send the plots to this utility, which would remember all of them. I could then navigate from frame to frame using its GUI. I think the plot utility was imagemagick, but I am not sure, because I cannot find any references to its GUI. Also I cannot find the documentation in gnuplot anymore :-( Thanks, Mirko |
|
From: Mirko V. <mir...@gm...> - 2009-03-24 21:00:20
|
Hello,
I get an error when I evaluate
*(.sqrt (.rseq -10 10 11))*
I am assuming because nlisp is trying to store a complex value into a double
array. Any way around that? I came up with this monstrosity:
(./ (.sqrt (.* #c(0 1) (.rseq -10 10 11)))
(sqrt #c(0 1)))
Here I multiply by #c(0 1) to make the argument to .sqrt complex - that
makes it initialize the array correctly, and then divide out by (sqrt i)
I also tried to create my own operator: (nlisp::make-f-1-arg .sqrt1 sqrt
:explicit-return-type 'n-complex-double-array)
but that fails if the result of the computation is a double.
argh :-)
|
|
From: <lei...@us...> - 2009-03-08 16:49:04
|
Revision: 192
http://nlisp.svn.sourceforge.net/nlisp/?rev=192&view=rev
Author: leighsmith
Date: 2009-03-08 16:49:02 +0000 (Sun, 08 Mar 2009)
Log Message:
-----------
Added gsll dependency.
Modified Paths:
--------------
trunk/nlisp.asd
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <lei...@us...> - 2009-03-08 12:01:55
|
Revision: 191
http://nlisp.svn.sourceforge.net/nlisp/?rev=191&view=rev
Author: leighsmith
Date: 2009-03-08 12:01:49 +0000 (Sun, 08 Mar 2009)
Log Message:
-----------
Reversed the addition of a linefeed, since this is inconsistent depending on the value of
*print-truncated-array-limit* and contradicts the print-object semantic, by assuming the
output device is a line based printer.
Modified Paths:
--------------
trunk/nlisp-class.lisp
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <mi...@us...> - 2009-02-26 12:55:13
|
Revision: 190
http://nlisp.svn.sourceforge.net/nlisp/?rev=190&view=rev
Author: mirkov
Date: 2009-02-26 12:46:49 +0000 (Thu, 26 Feb 2009)
Log Message:
-----------
Added ~% to properly end a format statement
Modified Paths:
--------------
trunk/nlisp-class.lisp
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: Mirko V. <mir...@gm...> - 2009-02-26 03:28:46
|
On Wed, Feb 25, 2009 at 5:45 PM, Leigh Smith <le...@le...> wrote: > Thanks Mirko for your feedback on save-plot. While the default format is > postscript, the :format keyword parameter to SAVE-PLOT allows specifying any > of the formats that gnuplot supports. > > We should have a routine to save all the plot data (and hopefully >> formatting parameters) into a file that can be read at a later date and used >> to restore a plot. I would find such a feature tremendously useful. >> Especially if the data in the restored plot can be read into a lisp >> session. >> > > I tend to feel that there are already routines in nlisp-io for saving the > data that is used to form the plot, .SAVE allows writing the data out in a > number of binary and text formats. There is a long standing plan to > implement saving to HDF5 format which can also benefit plotting. I find > writing a postscript file which is then converted to PDF (or using aquaterm > to directly write PDFs) in effect achieves that plot archiving for my > purposes. This could be achieved for those platforms that don't do PDF > plotting natively by SAVE-PLOT checking if the :format parameter is "PDF", > and if so, running a ps2pdf converter. Two points here: 1) There is definitely a need for documentation, which a long time ago I volunteered to write. I may start collecting your replies to my emails for that purpose. 2) My comment was driven by experience with software such as excel, which, paltry as it may be, saves the state of an analysis, and can then pick off from that point. I am not trying anything that ambitious. But my experience with IDL's iTools was very positive. The iTools were versatile plotting utilities. One could save the plot, and then open it later for further processing of the data. I liked that very, very much. In some sense, the later session would be much cleaner, because it consisted of only the data that I cared about at that later moment. Again, I am not shooting for anything that ambitious, but a basic save plot, and open it for further playing would be an improved experience. This is really a usability layer on top of basic nlisp. > > > Likewise, if the :format parameter was "archive", this would just cause > SAVE-PLOT to call .SAVE to write the data to some files. These could be read > back again with the standard file I/O routines (.LOAD). I personally don't > favour that approach since the idea of plot functions archiving data mixes > the two behaviours and I think this will just complicate the code. To me, > what we need is to slightly extend .SAVE to also handle lists of NARRAYs: > > (plot (list n-data1 n-data2) (list x-axes1 x-axes2)) > (save-plot :format postscript) > > can be: > > (.save (list (list n-data1 n-data2) (list x-axes1 x-axes2)) file :format > :binary) > then > (apply #'plot (.load file)) > I will look into .save > > > I am not sure how to implement that. As a start, each window should have >> an associated variable (object) that stores the names of the data files used >> by gnuplot, and the list of plot commands. Upon a (save-plot file-name) the >> files should be zipped into an archive and an additional file with plot >> commands stored in it as well. >> > > The problem I see is how to ensure the gnuplot commands that generate the > plot are archived properly such that they can recreate the plot you want. > Most gnuplot commands probably can just be replayed with the right data > filenames, but it means dealing with directories that will change between > when the plot is originally drawn and when they are replayed. > Again, harking back,to my idl experience, some 10 years ago I wrote an OO plotting application. The data and all the plot settings were part of an object. The main method, generating the plot, would build the command line out of the stored plot settings, and apply it to the stored data. This could be applied here to, using the already existing functionality. A plot object that would store the data and the plot settings. As noted above, this is one level above the basic nlisp, and would use much of the existing functionality. This of course, does not address your next issue, that of plots with huge numbers of data. For that, another approach might be necessary. > > > >> As for saving plots in other formats, how about using names such as >> `render' or `export'. `Dump' which I used is too hackerish. >> >> Maybe there is a better name than save-plot for saving plots. >> > > I'm certainly open to renaming SAVE-PLOT, but in naming it that, the > semantics were considered as that the plot itself is being saved (after it > has been displayed). So I don't have a problem with the concept of saving > the plot data and gnuplot commands, but I think it might be quite a bit of > work to get it running transparently. I also suspect the approach may not > scale all that well, recreating small plots from the original data is > practically the same amount of work as redrawing the image, but for large > complicated data sets, the plot is often downsampling and projecting to 2-D > the data to produce the image and so will be slower than drawing the PDF > whenever the plot is redrawn within gnuplot. Here I have to disagree with you. My understanding of the semantics is following: `save' & `restore' are kind of a pairing: you save a plot, and you read it back in. `export' or `convert' transforms a plot to a different format or display device. Here are some examples that I have on my computer: GhostView uses convert when saving into file formats and save-as when saving into file formats it can read back. Gimp uses save-as, but that is because it can read back all the formats that it saves into. Inkscape is similar to Gimp. But in addition it can `export' a bitmap. I think we should follow conventions used in other packages. Until nlisp learns to read back in .svg and .ps formats (entirely possible), we should be exporting to them and not saving to them. my 2 pennies (this issue is not the dealbreaker for me) Mirko |
|
From: Leigh S. <le...@le...> - 2009-02-26 02:48:55
|
Thanks Mirko for your feedback on save-plot. While the default format is postscript, the :format keyword parameter to SAVE-PLOT allows specifying any of the formats that gnuplot supports. > We should have a routine to save all the plot data (and hopefully > formatting parameters) into a file that can be read at a later date > and used to restore a plot. I would find such a feature > tremendously useful. Especially if the data in the restored plot > can be read into a lisp session. I tend to feel that there are already routines in nlisp-io for saving the data that is used to form the plot, .SAVE allows writing the data out in a number of binary and text formats. There is a long standing plan to implement saving to HDF5 format which can also benefit plotting. I find writing a postscript file which is then converted to PDF (or using aquaterm to directly write PDFs) in effect achieves that plot archiving for my purposes. This could be achieved for those platforms that don't do PDF plotting natively by SAVE-PLOT checking if the :format parameter is "PDF", and if so, running a ps2pdf converter. Likewise, if the :format parameter was "archive", this would just cause SAVE-PLOT to call .SAVE to write the data to some files. These could be read back again with the standard file I/O routines (.LOAD). I personally don't favour that approach since the idea of plot functions archiving data mixes the two behaviours and I think this will just complicate the code. To me, what we need is to slightly extend .SAVE to also handle lists of NARRAYs: (plot (list n-data1 n-data2) (list x-axes1 x-axes2)) (save-plot :format postscript) can be: (.save (list (list n-data1 n-data2) (list x-axes1 x-axes2)) file :format :binary) then (apply #'plot (.load file)) > I am not sure how to implement that. As a start, each window should > have an associated variable (object) that stores the names of the > data files used by gnuplot, and the list of plot commands. Upon a > (save-plot file-name) the files should be zipped into an archive and > an additional file with plot commands stored in it as well. The problem I see is how to ensure the gnuplot commands that generate the plot are archived properly such that they can recreate the plot you want. Most gnuplot commands probably can just be replayed with the right data filenames, but it means dealing with directories that will change between when the plot is originally drawn and when they are replayed. > > As for saving plots in other formats, how about using names such as > `render' or `export'. `Dump' which I used is too hackerish. > > Maybe there is a better name than save-plot for saving plots. I'm certainly open to renaming SAVE-PLOT, but in naming it that, the semantics were considered as that the plot itself is being saved (after it has been displayed). So I don't have a problem with the concept of saving the plot data and gnuplot commands, but I think it might be quite a bit of work to get it running transparently. I also suspect the approach may not scale all that well, recreating small plots from the original data is practically the same amount of work as redrawing the image, but for large complicated data sets, the plot is often downsampling and projecting to 2-D the data to produce the image and so will be slower than drawing the PDF whenever the plot is redrawn within gnuplot. Leigh -- Leigh M. Smith mailto:le...@le... http://www.leighsmith.com skype:aussieleighsmith |
|
From: Mirko V. <mir...@gm...> - 2009-02-25 19:45:42
|
Leigh has written a `save-plot' that saves the plot in post-script format. I think we should reserve the name save-plot to save a plot. What do I mean by that: We should have a routine to save all the plot data (and hopefully formatting parameters) into a file that can be read at a later date and used to restore a plot. I would find such a feature tremendously useful. Especially if the data in the restored plot can be read into a lisp session. I am not sure how to implement that. As a start, each window should have an associated variable (object) that stores the names of the data files used by gnuplot, and the list of plot commands. Upon a (save-plot file-name) the files should be zipped into an archive and an additional file with plot commands stored in it as well. As for saving plots in other formats, how about using names such as `render' or `export'. `Dump' which I used is too hackerish. Maybe there is a better name than save-plot for saving plots. Mirko |
|
From: <lei...@us...> - 2009-02-23 18:19:08
|
Revision: 189
http://nlisp.svn.sourceforge.net/nlisp/?rev=189&view=rev
Author: leighsmith
Date: 2009-02-23 18:19:05 +0000 (Mon, 23 Feb 2009)
Log Message:
-----------
Corrected issue when plotting multiple different sized vectors with a default x axis.
Modified Paths:
--------------
trunk/nlisp-gnuplot.lisp
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: Mirko V. <mir...@gm...> - 2009-02-21 23:24:07
|
I was looking at Leigh's save-plot code in nlisp-gnuplot. The default file name is plot.postscript. I believe the default extension is `ps'. Mirko |
|
From: <dw...@cp...> - 2009-02-21 15:24:06
|
Note: This is catered for in the new version. I'll release some code for you to play with soon... D >> Well, it was not that hard. I defined a helper function of two >> arguments that fixes the other arguments and then calls the five- >> argument function. Then I subjected that function to make-f-2-arg. >> >> But, one has to be a real lisp lover in order to prefer this to the >> built-in features of idl & matlab :-) >> > Usually that's where macros become useful: to hide the ugliness behind > a parameterised interface. > > > Leigh > -- > Leigh M. Smith > mailto:le...@le... > http://www.leighsmith.com > skype:aussieleighsmith > > > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Nlisp-developer mailing list > Nli...@li... > https://lists.sourceforge.net/lists/listinfo/nlisp-developer > |
|
From: Leigh S. <le...@le...> - 2009-02-20 23:49:34
|
> Well, it was not that hard. I defined a helper function of two > arguments that fixes the other arguments and then calls the five- > argument function. Then I subjected that function to make-f-2-arg. > > But, one has to be a real lisp lover in order to prefer this to the > built-in features of idl & matlab :-) > Usually that's where macros become useful: to hide the ugliness behind a parameterised interface. Leigh -- Leigh M. Smith mailto:le...@le... http://www.leighsmith.com skype:aussieleighsmith |
|
From: Mirko V. <mir...@gm...> - 2009-02-20 23:31:01
|
On Fri, Feb 20, 2009 at 5:02 PM, Mirko Vukovic <mir...@gm...>wrote: > Consider the following defun with five arguments that returns a scalar. > (defun f1-2-parallel-coaxial-rings (r1-inner r1-outer sep > r2-inner r2-outer) > > How to vectorize that? Do we need a reader macro here? (I only have a > foggy idea what they do) > > Cheers, > > Mirko > Well, it was not that hard. I defined a helper function of two arguments that fixes the other arguments and then calls the five-argument function. Then I subjected that function to make-f-2-arg. But, one has to be a real lisp lover in order to prefer this to the built-in features of idl & matlab :-) Mirko |
|
From: Mirko V. <mir...@gm...> - 2009-02-20 23:27:21
|
Consider the following defun with five arguments that returns a scalar.
(defun f1-2-parallel-coaxial-rings (r1-inner r1-outer sep
r2-inner r2-outer)
How to vectorize that? Do we need a reader macro here? (I only have a
foggy idea what they do)
Cheers,
Mirko
|
|
From: <mi...@us...> - 2009-02-20 20:23:38
|
Revision: 188
http://nlisp.svn.sourceforge.net/nlisp/?rev=188&view=rev
Author: mirkov
Date: 2009-02-20 20:23:30 +0000 (Fri, 20 Feb 2009)
Log Message:
-----------
Fixed bugs related to nlisp-unit-test loading
Modified Paths:
--------------
trunk/nlisp.asd
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <mi...@us...> - 2009-02-20 18:15:25
|
Revision: 187
http://nlisp.svn.sourceforge.net/nlisp/?rev=187&view=rev
Author: mirkov
Date: 2009-02-20 18:15:21 +0000 (Fri, 20 Feb 2009)
Log Message:
-----------
Added nlisp-gsll-unit-tests.lisp file to the dependency tree.Reformatted
svn commit nlisp.asd -m
Modified Paths:
--------------
trunk/nlisp.asd
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|