headers
Dmitri A. Sergatskov | 1 Oct 2008 01:47
Picon

Re: Plotting problems 3.1.51+

On Tue, Sep 30, 2008 at 5:44 PM, Michael D. Godfrey
<godfrey <at> isl.stanford.edu> wrote:

>   My main purpose in using fx = line();  was to manipulate the line
>   width so that plots which end up included in PDF will have thicker
>   width.  The current default width makes the lines hard to see, partcularly
>   if the plot is scaled down to an appropriate size for a paper.

I would not comment on the bug. But for this particular problem a workaround is
to specify parameters inside the plot() command, e.g.:

plot(lambda_sc, pl_sc*planck_lhbar,"1", linestyle", "-", "linewidth", 2);

(As a side comment -- I would use gnuplot directly for plots like this. )

Sincerely,

Dmitri.
--
Permalink | Reply | 1 comment |
headers
Michael D. Godfrey | 1 Oct 2008 02:04
Picon
Favicon

Re: Plotting problems 3.1.51+

>
> I would not comment on the bug. But for this particular problem a workaround is
> to specify parameters inside the plot() command, e.g.:
>
> plot(lambda_sc, pl_sc*planck_lhbar,"1", linestyle", "-", "linewidth", 2);
This works.  Thanks very much.  I thought I had tried that before without
success, but I probably typed something wrong.

Michael
Permalink | Reply | 0 comments |
headers
Ben Abbott | 1 Oct 2008 02:14
Picon
Gravatar

Re: Plotting problems 3.1.51+


On Sep 30, 2008, at 6:44 PM, Michael D. Godfrey wrote:

> 1. The grid command does not allow a second argument when the
>   first argument is "minor".  Looking at grid.m, this is a simple
>   problem, but there are choices about how to fix it.  Since
>   grid("minor") does toggle the minor grid lines as the documentation
>   says, one fix would be to change the documentation by eliminating
>   the description of the grid("minor", "on" | "off") capability.
>   Otherwise, simple change to the code will implement this.

Matlab does not document the second argument. So I'd say the doc- 
string should be corrected.

However, Matlab does allow

	grid (hax, 'minor')

where the grid in the axis the handle "hax" points to is changed.  
Octave's current sources do not respect this behavior.

For compatibility

	grid on			: turns grid on
	grid off			: turns grid off
	grid				: toggles grid
	grid minor		: toggles minor grid
	grid (hax, ...)		: performs subsequent command in axis "hax"

Ben
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ben Abbott | 1 Oct 2008 04:00
Picon
Gravatar

Re: Plotting problems 3.1.51+ [changeset]


On Sep 30, 2008, at 8:14 PM, Ben Abbott wrote:

>
> On Sep 30, 2008, at 6:44 PM, Michael D. Godfrey wrote:
>
>> 1. The grid command does not allow a second argument when the
>>  first argument is "minor".  Looking at grid.m, this is a simple
>>  problem, but there are choices about how to fix it.  Since
>>  grid("minor") does toggle the minor grid lines as the documentation
>>  says, one fix would be to change the documentation by eliminating
>>  the description of the grid("minor", "on" | "off") capability.
>>  Otherwise, simple change to the code will implement this.
>
> Matlab does not document the second argument. So I'd say the doc-
> string should be corrected.
>
> However, Matlab does allow
>
> 	grid (hax, 'minor')
>
> where the grid in the axis the handle "hax" points to is changed.
> Octave's current sources do not respect this behavior.
>
> For compatibility
>
> 	grid on			: turns grid on
> 	grid off			: turns grid off
> 	grid				: toggles grid
> 	grid minor		: toggles minor grid
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael D. Godfrey | 1 Oct 2008 05:51
Picon
Favicon

text files

>
> BTW, when we fix this problem, should we try to keep track of what the
> first line ending character is in the file and only recognize that as
> the line ending character, or should we allow a random mix of LF,
> CRLF, and CR[*]? 

I have had to deal with this more than would seem reasonable.  Some
editors only modify the EOL characters for the lines that they edit and
leave the other lines "as they were."  So, I have found files with a random
mixture of LF, CR,LF, and even LF,CR.  emacs (ugh) seems to do a fairly
good job of this, but I think that it only writes out using Linux LF.  
If it encounters
CR,LF it marks the file as "DOS"  and it may, under some conditions
write the file with CR,LF to preserve its DOS property. I do not know 
how far
through the file it looks when deciding this.  Since it reads the whole 
file before doing
much else, it could wait until it hits EOF  (another problem item, since 
there
still exist file which signal EOF by ^Z (0x1a)).  It may be OK to forget 
0x1a
in the modern age, and  it is pretty simple to just discard it.  But, 
there exist files
which are longer than the position of the first 0x1a character and the 
rest is trash,
or not.

It is likely a good idea to tell the user about "funny" characters found 
in text
files, so they can do something if needed.  The whole "7-bit ASCII" idea was
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francesco Potorti` | 1 Oct 2008 12:49
Picon

speed of statistics.m

I do not know whether this is a Debian problem or maybe corrected, but
in Debian, using Octave from testing and from unstable I see that,
contrary to my expectations, statistics is much slower in Octave 3.1:

octave3.0> version
ans = 3.0.1
octave3.0> t=cputime;statistics(1:35000);cputime-t
ans =  0.26002
octave3.0> t=cputime;statistics(1:35000);cputime-t
ans =  0.26001
octave3.0> t=cputime;statistics(1:35000);cputime-t
ans =  0.25602

octave3.1> version
ans = 3.1.51
octave3.1> t=cputime;statistics(1:35000);cputime-t
ans =  1.7001
octave3.1> t=cputime;statistics(1:35000);cputime-t
ans =  1.7161
octave3.1> t=cputime;statistics(1:35000);cputime-t
ans =  1.6521
Permalink | Reply | 4 comments |
headers
Jaroslav Hajek | 1 Oct 2008 13:01
Picon

Re: speed of statistics.m

On Wed, Oct 1, 2008 at 12:49 PM, Francesco Potorti` <Potorti <at> isti.cnr.it> wrote:
> I do not know whether this is a Debian problem or maybe corrected, but
> in Debian, using Octave from testing and from unstable I see that,
> contrary to my expectations, statistics is much slower in Octave 3.1:
>
> octave3.0> version
> ans = 3.0.1
> octave3.0> t=cputime;statistics(1:35000);cputime-t
> ans =  0.26002
> octave3.0> t=cputime;statistics(1:35000);cputime-t
> ans =  0.26001
> octave3.0> t=cputime;statistics(1:35000);cputime-t
> ans =  0.25602
>
>
> octave3.1> version
> ans = 3.1.51
> octave3.1> t=cputime;statistics(1:35000);cputime-t
> ans =  1.7001
> octave3.1> t=cputime;statistics(1:35000);cputime-t
> ans =  1.7161
> octave3.1> t=cputime;statistics(1:35000);cputime-t
> ans =  1.6521
>

`statistics' computes a number of characteristics. Could you identify
which one of them is causing the slowdown?

> _______________________________________________
> Bug-octave mailing list
(Continue reading)

Permalink | Reply | 3 comments |
headers
Francesco Potorti` | 1 Oct 2008 13:30
Picon

[manual] Specify what is the return value of strrep

No changelog for this trivial change.

I managed to put non-ascii7 characters in my name by setting the env var
HGENCODING=ISO-8859-15.

Now, does anyone know ho to pass additional parameters to the diff used
by 'hg export'?  I would like to pass -pb, but I cannot guess how.

# HG changeset patch
# User Francesco Potortì <pot <at> gnu.org>
# Date 1222860453 -7200
# Node ID 81277bb56fce8ebdcbe389a980793298081d30b8
# Parent  364d9c8e033ed6512482c4572cdf05f529492b76
Specify what is the return value.

diff -r 364d9c8e033e -r 81277bb56fce scripts/strings/strrep.m
--- a/scripts/strings/strrep.m	Sat Sep 27 15:45:48 2008 +0200
+++ b/scripts/strings/strrep.m	Wed Oct 01 13:27:33 2008 +0200
 <at>  <at>  -20,7 +20,7  <at>  <at> 
 ## -*- texinfo -*-
 ##  <at> deftypefn {Function File} {} strrep ( <at> var{s},  <at> var{x},  <at> var{y})
 ## Replaces all occurrences of the substring  <at> var{x} of the string  <at> var{s}
-## with the string  <at> var{y}.  For example,
+## with the string  <at> var{y} and returns the result.  For example,
 ##
 ##  <at> example
 ## strrep ("This is a test string", "is", "&%$")
 <at>  <at>  -79,7 +79,7  <at>  <at> 
     t(dest) = y(repeat);
   else                        # deletion
(Continue reading)

Permalink | Reply | 2 comments |
headers
Francesco Potorti` | 1 Oct 2008 13:43
Picon

Re: speed of statistics.m

>> contrary to my expectations, statistics is much slower in Octave 3.1:
>>
>> octave3.0> t=cputime;statistics(1:35000);cputime-t
>> ans =  0.26002
>>
>> octave3.1> t=cputime;statistics(1:35000);cputime-t
>> ans =  1.6521
>
>`statistics' computes a number of characteristics. Could you identify
>which one of them is causing the slowdown?

Sorry, bad report :(

It turns out that while the nan package does not significantly affect
the speed of statistics() in 3.0, it severely slows them down in 3.1.

In fact, without the nan package, 3.1 is much faster, as I expected by
looking at the code.
Permalink | Reply | 1 comment |
headers
David Bateman | 1 Oct 2008 14:12

Re: speed of statistics.m

Jaroslav Hajek wrote:
> On Wed, Oct 1, 2008 at 12:49 PM, Francesco Potorti` <Potorti <at> isti.cnr.it> wrote:
>   
>> I do not know whether this is a Debian problem or maybe corrected, but
>> in Debian, using Octave from testing and from unstable I see that,
>> contrary to my expectations, statistics is much slower in Octave 3.1:
>>
>> octave3.0> version
>> ans = 3.0.1
>> octave3.0> t=cputime;statistics(1:35000);cputime-t
>> ans =  0.26002
>> octave3.0> t=cputime;statistics(1:35000);cputime-t
>> ans =  0.26001
>> octave3.0> t=cputime;statistics(1:35000);cputime-t
>> ans =  0.25602
>>
>>
>> octave3.1> version
>> ans = 3.1.51
>> octave3.1> t=cputime;statistics(1:35000);cputime-t
>> ans =  1.7001
>> octave3.1> t=cputime;statistics(1:35000);cputime-t
>> ans =  1.7161
>> octave3.1> t=cputime;statistics(1:35000);cputime-t
>> ans =  1.6521
>>
>>     
>
> `statistics' computes a number of characteristics. Could you identify
> which one of them is causing the slowdown?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane