torch5-bugs Mailing List for Torch5: fast machine learning toolbox
Status: Pre-Alpha
Brought to you by:
andresy
Menu
▾
▴
torch5-bugs — Torch5 bugs
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(23) |
Nov
(5) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2011-08-09 17:20:14
|
Bugs item #3389129, was opened at 2011-08-09 19:20 Message generated for change (Tracker Item Submitted) made by patrick_zanon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=3389129&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patrick (patrick_zanon) Assigned to: Nobody/Anonymous (nobody) Summary: Torch5 for Debian Lenny Initial Comment: Torch5 cannot be packaged into Debian Lenny due to an invalid dependency: in Debian atlas3-base has a different name than in Ubuntu: libatlas3gf-base vs atlas3-base. I enclosed a patch to solve this small problem into Debian, and also respecting the different package names used in Ubuntu. The section has also changed to from "devel" to "math" (like in octave...). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=3389129&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2011-08-09 17:18:55
|
Bugs item #3389127, was opened at 2011-08-09 19:18 Message generated for change (Tracker Item Submitted) made by patrick_zanon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=3389127&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patrick (patrick_zanon) Assigned to: Nobody/Anonymous (nobody) Summary: Torch5 fails to manage iterators into Min and Max functions. Initial Comment: Since a lot of time ago Torch 5 uses a "long" iterator rather than the old "int" one. However Min and Max functions still use an "int" iterator. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=3389127&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2011-08-09 17:14:43
|
Bugs item #3389124, was opened at 2011-08-09 19:14 Message generated for change (Tracker Item Submitted) made by patrick_zanon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=3389124&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patrick (patrick_zanon) Assigned to: Nobody/Anonymous (nobody) Summary: Min and Max fail to manage a 1D Tensor Initial Comment: Min and Max functions fail to manage the 1D tensors, since the code tries to reduce the dimensionality by calling the THTensor_select function, and by adjusting the gradOutputPlusOneDim by adding one dimension... Of course, none of these steps are necessary when working with 1D tensors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=3389124&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2011-08-09 16:59:08
|
Bugs item #3389119, was opened at 2011-08-09 18:59 Message generated for change (Tracker Item Submitted) made by patrick_zanon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=3389119&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patrick (patrick_zanon) Assigned to: Nobody/Anonymous (nobody) Summary: Tensor printing and min/max do not handle nans Initial Comment: Tensor printing and min/max do not handle the presence of nans. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=3389119&group_id=183526 |
|
From: Patrick Z. <pat...@gm...> - 2011-03-10 06:03:35
|
Dear developers, Tensor printing and min/max do not handle the presence of nans; I enclosed a patch with a proposed correction Cordially, Patrick Zanon |
|
From: Patrick Z. <pat...@gm...> - 2011-03-10 05:59:18
|
Dear developers, Min and Max functions fail to manage the 1D tensors, since the code tries to reduce the dimensionality by calling the THTensor_select function, and by adjusting the gradOutputPlusOneDim by adding one dimension... Of course, none of these steps are necessary when working with 1D tensors. I enclosed a patch that should solve the problem. Cordially, Patrick Zanon |
|
From: Patrick Z. <pat...@gm...> - 2011-03-10 05:52:17
|
Dear developers, Since a lot of time ago Torch 5 uses a "long" iterator rather than the old "int" one. However Min and Max functions still use an "int" iterator. I enclosed a patch that should solve the problem. Cordially, Patrick Zanon |
|
From: Patrick Z. <pat...@gm...> - 2011-03-10 05:46:32
|
Dear developers, Torch5 cannot be packaged into Debian Lenny due to an invalid dependency: in Debian atlas3-base has a different name than in Ubuntu: libatlas3gf-base vs atlas3-base. I enclosed a patch to solve this small problem into Debian, and also respecting the different package names used in Ubuntu. The section has also changed to from "devel" to "math" (like in octave...). Cordially, Patrick Zanon |
|
From: SourceForge.net <no...@so...> - 2008-08-08 15:15:08
|
Bugs item #2042208, was opened at 2008-08-07 21:34 Message generated for change (Comment added) made by andresy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=2042208&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: David Grangier (grangier) Assigned to: Nobody/Anonymous (nobody) Summary: Matrix multiply yields segfault Initial Comment: require 'torch' require 'lab' x=torch.Tensor(10,15,3) for i=1,10 do for j=1,15 do for k=1,3 do x[i][j][k] = k end end end y=lab.reshape(x,150,3) m=lab.mean(y) z=y*m:t() ---------------------------------------------------------------------- >Comment By: Raoul d'Andresy (andresy) Date: 2008-08-08 15:15 Message: Logged In: YES user_id=1651867 Originator: NO Blas is sensitive to strides in a matrix, even if the number of columns is 1. THBlas has been changed to handle this particular case. Problem fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=2042208&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2008-08-07 21:34:06
|
Bugs item #2042208, was opened at 2008-08-07 17:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=2042208&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Grangier (grangier) Assigned to: Nobody/Anonymous (nobody) Summary: Matrix multiply yields segfault Initial Comment: require 'torch' require 'lab' x=torch.Tensor(10,15,3) for i=1,10 do for j=1,15 do for k=1,3 do x[i][j][k] = k end end end y=lab.reshape(x,150,3) m=lab.mean(y) z=y*m:t() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=2042208&group_id=183526 |
|
From: Iain M. <iai...@gm...> - 2008-03-07 02:34:19
|
this was my stupid fault - some exception code was commented out. There is a nice error message really. sorry, Iain On Fri, Feb 29, 2008 at 1:21 PM, Iain Melvin <iai...@gm...> wrote: > on cygwin this causes a nasty hang.. > > x=torch.Tensor(2,0) > y=x:narrow(2,1,1) > > I know it doesn't make sense, but there it is.. > Iain > |
|
From: Iain M. <iai...@gm...> - 2008-02-29 18:21:02
|
on cygwin this causes a nasty hang.. x=torch.Tensor(2,0) y=x:narrow(2,1,1) I know it doesn't make sense, but there it is.. Iain |
|
From: SourceForge.net <no...@so...> - 2007-12-14 04:54:01
|
Bugs item #1850502, was opened at 2007-12-14 04:06 Message generated for change (Comment added) made by andresy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1850502&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 9 Private: No Submitted By: Raoul d'Andresy (andresy) Assigned to: Raoul d'Andresy (andresy) Summary: TensorIterator has a bug Initial Comment: TensorIterator does not work when the data is not contiguous in memory. E.g.: after a transpose on a 2D tensor. Scary, as it has an impact on a lot of operations. ---------------------------------------------------------------------- >Comment By: Raoul d'Andresy (andresy) Date: 2007-12-14 04:54 Message: Logged In: YES user_id=1651867 Originator: YES Corrected. Note: it had only an impact on Tensor where the trailing contiguous dimensions is > 1. Did not have an impact on all the neural net I tested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1850502&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2007-12-14 04:06:04
|
Bugs item #1850502, was opened at 2007-12-14 04:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1850502&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 9 Private: No Submitted By: Raoul d'Andresy (andresy) Assigned to: Raoul d'Andresy (andresy) Summary: TensorIterator has a bug Initial Comment: TensorIterator does not work when the data is not contiguous in memory. E.g.: after a transpose on a 2D tensor. Scary, as it has an impact on a lot of operations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1850502&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2007-11-27 20:45:56
|
Bugs item #1839716, was opened at 2007-11-27 19:24 Message generated for change (Comment added) made by andresy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1839716&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: thespermwhale (thespermwhale) Assigned to: Raoul d'Andresy (andresy) Summary: BLAS problem with 1-dim tensors? Initial Comment: I get this: lda must be >= MAX(M,1): lda=1 M=2Parameter 7 to routine cblas_dgemv was incorrect [quits out of lua] when I run this: require "torch" require "nn" mlp= nn.Sequential(); mlp:add(nn.Linear(1,2)) x=torch.Tensor(1) print(mlp:forward(x)) Without BLAS, it works. ---------------------------------------------------------------------- >Comment By: Raoul d'Andresy (andresy) Date: 2007-11-27 20:46 Message: Logged In: YES user_id=1651867 Originator: NO this was because blas relies on the stride of the matrix (in the second dimension), even if the number of column is 1!! strange, i would say. but corrected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1839716&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2007-11-27 19:24:20
|
Bugs item #1839716, was opened at 2007-11-27 14:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1839716&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: thespermwhale (thespermwhale) Assigned to: Raoul d'Andresy (andresy) Summary: BLAS problem with 1-dim tensors? Initial Comment: I get this: lda must be >= MAX(M,1): lda=1 M=2Parameter 7 to routine cblas_dgemv was incorrect [quits out of lua] when I run this: require "torch" require "nn" mlp= nn.Sequential(); mlp:add(nn.Linear(1,2)) x=torch.Tensor(1) print(mlp:forward(x)) Without BLAS, it works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1839716&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2007-11-15 05:44:19
|
Bugs item #1797566, was opened at 2007-09-19 01:11 Message generated for change (Comment added) made by andresy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1797566&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Raoul d'Andresy (andresy) Summary: doc bug Initial Comment: Archiver help says seek(0) in an example but isn't it seek(1)??: Interestingly, if the File object given to an Archiver is a MemoryFile [*5], it allows the user to easily make a clone of any Torch object: file = torch.Archiver() -- creates an Archiver over MemoryFile file:writeObject(object) file:seek(0) objectClone = file:readObject() ---------------------------------------------------------------------- >Comment By: Raoul d'Andresy (andresy) Date: 2007-11-15 05:44 Message: Logged In: YES user_id=1651867 Originator: NO fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1797566&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2007-11-01 02:28:23
|
Bugs item #1823820, was opened at 2007-11-01 02:27 Message generated for change (Comment added) made by andresy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1823820&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 8 Private: No Submitted By: Raoul d'Andresy (andresy) Assigned to: Raoul d'Andresy (andresy) Summary: MemoryFile bugs Initial Comment: - MemoryFile is slow when in ascii mode - MemoryFile has a bug when reading in binary mode: the data obtained is not the one at the right position, but seems to be at a previous position! ---------------------------------------------------------------------- >Comment By: Raoul d'Andresy (andresy) Date: 2007-11-01 02:28 Message: Logged In: YES user_id=1651867 Originator: YES The slowliness in ascii was coming from sscanf which is insanely slow on long strings. A workaround (implemented) is to split the string in smaller ones. The reading bug in binary mode has been also corrected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1823820&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2007-11-01 02:26:55
|
Bugs item #1823820, was opened at 2007-11-01 02:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1823820&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 8 Private: No Submitted By: Raoul d'Andresy (andresy) Assigned to: Raoul d'Andresy (andresy) Summary: MemoryFile bugs Initial Comment: - MemoryFile is slow when in ascii mode - MemoryFile has a bug when reading in binary mode: the data obtained is not the one at the right position, but seems to be at a previous position! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1823820&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2007-10-27 00:40:14
|
Bugs item #1797568, was opened at 2007-09-19 01:14 Message generated for change (Comment added) made by andresy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1797568&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Raoul d'Andresy (andresy) Summary: nn.Sequential -- no way of getting :size() Initial Comment: we should be able to do something like: mlp=nn.Sequential() mlp:add(nn.Linear(5,5)) print(mlp:size()) by the way, why is it mlp:get(1) when for everything else one uses square brackets [] ? would it be possible to simply make nn.Sequential inherit from Array in that regard or something? or .. ---------------------------------------------------------------------- >Comment By: Raoul d'Andresy (andresy) Date: 2007-10-27 00:40 Message: Logged In: YES user_id=1651867 Originator: NO iain added the :size() method apparently ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1797568&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2007-10-27 00:24:51
|
Bugs item #1797573, was opened at 2007-09-19 01:20 Message generated for change (Settings changed) made by andresy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1797573&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: thespermwhale (thespermwhale) Assigned to: Raoul d'Andresy (andresy) Summary: Bug in deep copy produced by memory files Initial Comment: Somehow the deep copy is actually only a shallow copy.. This code shows the bug: require "torch" require "nn" mlp= nn.Sequential(); mlp:add(nn.Linear(5,1)) -- create a deepcopy of the mlp file = torch.Archiver(); file:writeObject(mlp); file:seek(1) mlp_tmp = file:readObject() mlp_tmp:get(1).weight[1][1]=99 print(mlp_tmp:get(1).weight) print(mlp:get(1).weight) ---------------------------------------------------------------------- Comment By: Raoul d'Andresy (andresy) Date: 2007-10-27 00:24 Message: Logged In: YES user_id=1651867 Originator: NO this bug was actually not related to memory files, but to Archiver: because of the tree of objects it generates internally it is non-sense to use an Archiver in read-write mode. all the files now can be open open in "r", "w" or "rw" mode (read/write/read-write). by default MemoryFile opens in "rw". an Archiver can be open only in "r" or "w" mode. asking for the file possibility is done by methods isReadable() and isWritable(). to achieve what Jason wanted to do, one can now do: (1) f = torch.MemoryFile() -- opened in "rw" mode by default (2) a = torch.Archiver(f, "w") -- we want to write some stuff (3) a:writeObject(mlp) -- we write some stuff (4) a = torch.Archiver(f, "r") -- we want to read now! (5) a:seek(1) -- seek at the beginning (6) obj = a:readObject() -- we got a clone of the mlp! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1797573&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2007-10-27 00:24:31
|
Bugs item #1797573, was opened at 2007-09-19 01:20 Message generated for change (Comment added) made by andresy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1797573&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: thespermwhale (thespermwhale) Assigned to: Raoul d'Andresy (andresy) Summary: Bug in deep copy produced by memory files Initial Comment: Somehow the deep copy is actually only a shallow copy.. This code shows the bug: require "torch" require "nn" mlp= nn.Sequential(); mlp:add(nn.Linear(5,1)) -- create a deepcopy of the mlp file = torch.Archiver(); file:writeObject(mlp); file:seek(1) mlp_tmp = file:readObject() mlp_tmp:get(1).weight[1][1]=99 print(mlp_tmp:get(1).weight) print(mlp:get(1).weight) ---------------------------------------------------------------------- >Comment By: Raoul d'Andresy (andresy) Date: 2007-10-27 00:24 Message: Logged In: YES user_id=1651867 Originator: NO this bug was actually not related to memory files, but to Archiver: because of the tree of objects it generates internally it is non-sense to use an Archiver in read-write mode. all the files now can be open open in "r", "w" or "rw" mode (read/write/read-write). by default MemoryFile opens in "rw". an Archiver can be open only in "r" or "w" mode. asking for the file possibility is done by methods isReadable() and isWritable(). to achieve what Jason wanted to do, one can now do: (1) f = torch.MemoryFile() -- opened in "rw" mode by default (2) a = torch.Archiver(f, "w") -- we want to write some stuff (3) a:writeObject(mlp) -- we write some stuff (4) a = torch.Archiver(f, "r") -- we want to read now! (5) a:seek(1) -- seek at the beginning (6) obj = a:readObject() -- we got a clone of the mlp! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1797573&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2007-10-27 00:17:12
|
Bugs item #1797571, was opened at 2007-09-19 01:17 Message generated for change (Comment added) made by andresy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1797571&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: thespermwhale (thespermwhale) Assigned to: Raoul d'Andresy (andresy) Summary: quiet() doesn\'t work for memory files Initial Comment: quiet() doesn't work for memory files Example code for bug: require "nn" mlp= nn.Sequential(); mlp:add(nn.Linear(5,10)) mlp:add(nn.Linear(10,1)) file = torch.Archiver() -- creates an Archiver over MemoryFile file:quiet(); file:writeObject(mlp) file:seek(1) while true do file:quiet(); t=file:readChar(); print(t, file:hasError()) end ---------- It's because Archiver doesn't send this message to the memory file underneath. Adding the line "file:file():quiet()" actually makes it work.. ---------------------------------------------------------------------- >Comment By: Raoul d'Andresy (andresy) Date: 2007-10-27 00:17 Message: Logged In: YES user_id=1651867 Originator: NO quiet() works now after a big rewriting of the File stuff! ---------------------------------------------------------------------- Comment By: thespermwhale (thespermwhale) Date: 2007-09-19 01:19 Message: Logged In: YES user_id=1660532 Originator: YES Also, the function file() mentioned above is not documented. ---------------------------------------------------------------------- Comment By: thespermwhale (thespermwhale) Date: 2007-09-19 01:17 Message: Logged In: YES user_id=1660532 Originator: YES Note that, perhaps in the same way, endSeek() doesn't work either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1797571&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2007-10-10 19:41:47
|
Bugs item #1811080, was opened at 2007-10-10 14:25 Message generated for change (Settings changed) made by thespermwhale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1811080&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 4 Private: No Submitted By: Raoul d'Andresy (andresy) Assigned to: thespermwhale (thespermwhale) Summary: legend display problem Initial Comment: while i am unable to plot with lines, the legend box generated with legend() command shows the mark of my plots crossed by a line. so if i plot with 'ro', there is not solid line generated, but the legend displays a 'o' crossed by a line. also, when i plot many plots (12 right now), the legend box is a way to big compare to its contents (a lot of white space in the bottom of the box). ---------------------------------------------------------------------- Comment By: Raoul d'Andresy (andresy) Date: 2007-10-10 14:50 Message: Logged In: YES user_id=1651867 Originator: YES the space problem is fixed, good. there is only the crossed 'o' problem (or any other mark) in the legend when not in solid (or dashed) lines mode. ---------------------------------------------------------------------- Comment By: Raoul d'Andresy (andresy) Date: 2007-10-10 14:47 Message: Logged In: YES user_id=1651867 Originator: YES thanks for the "minus" thing. well, now the legend is still wrong when one plots with 'ro' for e.g.: the 'o' is a legend is crossed. if one plots with 'ro-', it is good. is it how matlab does btw? (i thought solid lines were the default, but i do not have matlab) the space at the bottom of the legend is still here, maybe a font size problem, which might differ from one system to another one? ---------------------------------------------------------------------- Comment By: thespermwhale (thespermwhale) Date: 2007-10-10 14:44 Message: Logged In: YES user_id=1660532 Originator: NO hi, i think that it's fixed -- tell me if it's not so? ---------------------------------------------------------------------- Comment By: thespermwhale (thespermwhale) Date: 2007-10-10 14:33 Message: Logged In: YES user_id=1660532 Originator: NO did removing the minus fix the first part of this? ---------------------------------------------------------------------- Comment By: thespermwhale (thespermwhale) Date: 2007-10-10 14:32 Message: Logged In: YES user_id=1660532 Originator: NO did removing the minus fix the first part of this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1811080&group_id=183526 |
|
From: SourceForge.net <no...@so...> - 2007-10-10 18:50:32
|
Bugs item #1811080, was opened at 2007-10-10 18:25 Message generated for change (Comment added) made by andresy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1811080&group_id=183526 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 4 Private: No Submitted By: Raoul d'Andresy (andresy) Assigned to: thespermwhale (thespermwhale) Summary: legend display problem Initial Comment: while i am unable to plot with lines, the legend box generated with legend() command shows the mark of my plots crossed by a line. so if i plot with 'ro', there is not solid line generated, but the legend displays a 'o' crossed by a line. also, when i plot many plots (12 right now), the legend box is a way to big compare to its contents (a lot of white space in the bottom of the box). ---------------------------------------------------------------------- >Comment By: Raoul d'Andresy (andresy) Date: 2007-10-10 18:50 Message: Logged In: YES user_id=1651867 Originator: YES the space problem is fixed, good. there is only the crossed 'o' problem (or any other mark) in the legend when not in solid (or dashed) lines mode. ---------------------------------------------------------------------- Comment By: Raoul d'Andresy (andresy) Date: 2007-10-10 18:47 Message: Logged In: YES user_id=1651867 Originator: YES thanks for the "minus" thing. well, now the legend is still wrong when one plots with 'ro' for e.g.: the 'o' is a legend is crossed. if one plots with 'ro-', it is good. is it how matlab does btw? (i thought solid lines were the default, but i do not have matlab) the space at the bottom of the legend is still here, maybe a font size problem, which might differ from one system to another one? ---------------------------------------------------------------------- Comment By: thespermwhale (thespermwhale) Date: 2007-10-10 18:44 Message: Logged In: YES user_id=1660532 Originator: NO hi, i think that it's fixed -- tell me if it's not so? ---------------------------------------------------------------------- Comment By: thespermwhale (thespermwhale) Date: 2007-10-10 18:33 Message: Logged In: YES user_id=1660532 Originator: NO did removing the minus fix the first part of this? ---------------------------------------------------------------------- Comment By: thespermwhale (thespermwhale) Date: 2007-10-10 18:32 Message: Logged In: YES user_id=1660532 Originator: NO did removing the minus fix the first part of this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=905598&aid=1811080&group_id=183526 |
