Martin Helm wrote:
>
> Then in addition a question to everyone: Isn't it better to find a solution
> for gnuplot which works with triangles (and may be quadrilaterals) for the
> moment as intermediate step instead of a simple error message telling us that
> nothing is possible?
> At least it w
On Mar 9, 2009, at 3:36 AM, Thomas Treichl wrote:
> Søren Hauberg schrieb:
>> søn, 08 03 2009 kl. 16:48 +0100, skrev Martin Helm:
>>> Ok, I simply did not know when 3.2 will be released, so it seems
>>> to me that it is not a problem skipping the 3.0.x version and
>>> focus on 3.2.
>> No date
On Sun, Mar 08, 2009 at 01:14:49PM -0600, Daniel J Sebald wrote:
> Martin,
>
> Using depthorder is creative. I'd like to point out that depthorder is
> only an approximation to what should be "hidden surfaces". I worked on
> many aspects of gnuplot. Although gnuplot does have a hidden line
>
Martin Helm wrote:
>>I've always felt motivated to write a hidden surface algorithm but hadn't
>>found the time given how much work that would require. Even the syntax
>>"depthorder" would be nice to deprecate, and instead simply refer to it as
>>"hidden".
>>
>
>
> The problem with a general h
> Martin,
>
> Using depthorder is creative. I'd like to point out that depthorder is
> only an approximation to what should be "hidden surfaces". I worked on
> many aspects of gnuplot. Although gnuplot does have a hidden line
> algorithm (i.e., it can break a mesh into line segments--based on
>
Martin,
Using depthorder is creative. I'd like to point out that depthorder is only an
approximation to what should be "hidden surfaces". I worked on many aspects of
gnuplot. Although gnuplot does have a hidden line algorithm (i.e., it can
break a mesh into line segments--based on intersecti
Søren Hauberg schrieb:
> søn, 08 03 2009 kl. 16:48 +0100, skrev Martin Helm:
>> Ok, I simply did not know when 3.2 will be released, so it seems to me that
>> it
>> is not a problem skipping the 3.0.x version and focus on 3.2.
>
> No date is currently fixed, but we're hoping for a release in th
* Tried to downgrade to libmyodbc_3.51.11-6.1_i386.deb. ..no luck.. same
error.
* Tried to comment out "ifdef HAVE_ODBC.. endif" in makefile. ..no luck..
same error.
* Tried to comment out odbc statment in PKG_ADD ..no luck.. same error.
/Anders
2009/3/8 kalle boll
> Dear database package mai
On Sun, Mar 08, 2009 at 05:19:39PM +0100, S?ren Hauberg wrote:
> For this, I'd say 'maintainers'. I'd recommend starting a thread on this
> list about creating 3D patches in gnuplot. Just sketch your idea and see
> if people have any comments. Perhaps somebody tried your idea before and
> failed. A
Dear database package maintainers and forge developers,
I detected this bug when running a database package install on Open Suse
(stable/latest updates - ia64) and Ubuntu (8.10 and Jaunty alpha 5 - i388).
This happens with Octave 3.0.0, 3.0.1 and 3.0.4.
"octave:7> pkg install database-1.0.1.tar.g
søn, 08 03 2009 kl. 16:48 +0100, skrev Martin Helm:
> Ok, I simply did not know when 3.2 will be released, so it seems to me that
> it
> is not a problem skipping the 3.0.x version and focus on 3.2.
No date is currently fixed, but we're hoping for a release in the near
future.
> But you can st
> søn, 08 03 2009 kl. 01:04 +0100, skrev Martin Helm:
> > thank you for your responses. I have no strong opinion about the right
> > place for the functions. There are reasons to put it into the core (in
> > matlab these are core functions), but there are also good reasons not to
> > do that now. M
On Sun, Mar 8, 2009 at 10:09 AM, Søren Hauberg wrote:
> fre, 27 02 2009 kl. 14:03 +0100, skrev Jaroslav Hajek:
>> in case anyone is interested, I committed today into the "general"
>> package an initial m-file implementation of parcellfun.
>> parcellfun is supposed to be able to evaluate a given f
søn, 08 03 2009 kl. 10:49 +0100, skrev Jaroslav Hajek:
> OK, I see the problem. Attached an update.
It looks like it works. Thanks.
> Interesting, but maybe it can't be generalized? I get:
>
> octave:1> data = rand (1, 20);
> octave:2> na_data = data; na_data (6, 1) = na_data (7, 2) = NA;
>
On Sun, Mar 8, 2009 at 10:06 AM, Søren Hauberg wrote:
> søn, 08 03 2009 kl. 09:40 +0100, skrev Jaroslav Hajek:
>> 1. "use all" -> "all" etc - I think this is more Octavish
>
> Agreed.
>
>> 2. covariances of zero-length vectors are returned as NA. covariances
>> of length 1 vectors are zero.
>
> Ma
fre, 27 02 2009 kl. 14:03 +0100, skrev Jaroslav Hajek:
> in case anyone is interested, I committed today into the "general"
> package an initial m-file implementation of parcellfun.
> parcellfun is supposed to be able to evaluate a given function for
> multiple sets of input arguments using multipl
søn, 08 03 2009 kl. 09:40 +0100, skrev Jaroslav Hajek:
> 1. "use all" -> "all" etc - I think this is more Octavish
Agreed.
> 2. covariances of zero-length vectors are returned as NA. covariances
> of length 1 vectors are zero.
Makes sense.
> 3. vectorizing the "pairs" case was really tricky (du
On Sun, Mar 8, 2009 at 12:03 AM, Søren Hauberg wrote:
> lør, 07 03 2009 kl. 22:57 +0100, skrev Søren Hauberg:
>> > Two ways of deletion is supported. If, e.g, 3 dimensional vector is
>> > observed where one of the values are NA, then
>> >
>> > 1) the entire observation is deleted, or
>> >
>> >
søn, 08 03 2009 kl. 01:04 +0100, skrev Martin Helm:
> thank you for your responses. I have no strong opinion about the right place
> for the functions. There are reasons to put it into the core (in matlab these
> are core functions), but there are also good reasons not to do that now.
> My main r
19 matches
Mail list logo
