On Wed, May 14, 2008 at 1:29 AM, MYH <[EMAIL PROTECTED]> wrote:
> Hi.
>
> I found that when print a figure, if one other window overlaps on the top
> of the figure window,
> the print will contain the overlapping window. It looks like this:
> http://p8.p.pixnet.net/albums/userpics/8/3/553683/1
Hi,
Could you please register me as an Octave-Forge developer?
I have some code that was written in Matlab, and I've been trying to
make it Octave compatible. Part of it uses the fminbnd function, however
the Octave-Forge function is not as fast as the Matlab one because it
does not use parabol
Hi Everyone,
I recently moved to Octave 3.01, and found that the nice quick easy
install of everything at once in octave-forge has been moved to package
installs, and octave-forge is not in the easy to install synaptic
repository. I tried to install the Optim package and I keep having
problems wi
Hi.
I found that when print a figure, if one other window overlaps on the top of
the figure window,
the print will contain the overlapping window. It looks like this:
http://p8.p.pixnet.net/albums/userpics/8/3/553683/1210721149.png
This wouldn't occur in MATLAB.
This is my command:
x = -pi:0.01:
I have looked up matlab (TM)'s answers at a friend's workstation:
>
>> betainc (.75, 2047, .5)
>
> 4.437e-258
matlab: 4.437e-258
>
>> betainc (.85, 2047, .5)
>
> 0
matlab: 1.0659e-146
> ^^ If it returned a zero for .85, it should either do likewise for
> .75, or it should return a better ans
>> [ tcdf bug reported]
>>
>>
>
> This is an octave core function and so issues should be reported to
> [EMAIL PROTECTED] That being said you should upgrade from 2.1.73 as that
> is a very old version of Octave. The latest stable release is 3.0.1.
> Also the t_cdf function had its name changed
Michael Grossbach wrote:
> There seems to be a bug in textread (Octave 3.0.1 binary from
> sourceforge, Windows XP) related to the 'headerlines' parameter.
> Assume the following in a file test.txt (without the start and end tags):
As this is currently an octave-forge function the bug should be s
On Tue, May 13, 2008 at 6:07 PM, David Bateman
<[EMAIL PROTECTED]> wrote:
>
> MYH wrote:
> > Hi.
> >
> > It seems I found a bug in octave 3.0.1 for Windows.
> > When I run these commands:
> > x = -pi:0.01:pi;
> > plot(x, sin(x));
> >
> > on Windows XP, the gnuplot appeared but froze.
> > T
Dave Goel wrote:
> I have looked up matlab (TM)'s answers at a friend's workstation:
>
>>> betainc (.75, 2047, .5)
>> 4.437e-258
>
> matlab: 4.437e-258
>
>>> betainc (.85, 2047, .5)
>> 0
>
> matlab: 1.0659e-146
>
>
>> ^^ If it returned a zero for .85, it should either do likewise for
>> .75,
David Bateman wrote:
Raymond E. Rogers wrote:
Can somebody point me to an careful explanation (for us old folks who
are slow of wit) on how to see the results of the embedded documentation
for a particular package. I want to include the @tek and would like to
see how it's going to look bef
MYH wrote:
> Hi.
>
> It seems I found a bug in octave 3.0.1 for Windows.
> When I run these commands:
> x = -pi:0.01:pi;
> plot(x, sin(x));
>
> on Windows XP, the gnuplot appeared but froze.
> This is my screen shot:
> http://p8.p.pixnet.net/albums/userpics/8/3/553683/1210677251.png
>
I've seen
Hi.
It seems I found a bug in octave 3.0.1 for Windows.
When I run these commands:
x = -pi:0.01:pi;
plot(x, sin(x));
on Windows XP, the gnuplot appeared but froze.
This is my screen shot:
http://p8.p.pixnet.net/albums/userpics/8/3/553683/1210677251.png-
On Tue, May 13, 2008 at 1:45 AM, Michael Goffioul
<[EMAIL PROTECTED]> wrote:
> Here's a patch that make the video package work with
> the recent SVN version of FFMpeg.
I checked this in. This will break the build for some people. Putting
the entire ffmpeg tree into svn may be the way to go-- but
Raymond E. Rogers wrote:
> Can somebody point me to an careful explanation (for us old folks who
> are slow of wit) on how to see the results of the embedded documentation
> for a particular package. I want to include the @tek and would like to
> see how it's going to look before publishing.
>
Dave Goel wrote:
> The zeros are not just a matter of "inconvenience". As seen here,
> octave's results for this cdf are not even monotonous (cdf should
> always be monotonously increasing). In other words, as you go left,
> the area under the curve increases(!).
>
>
>
> octave:23> t_cdf (-29,4094
15 matches
Mail list logo
