Are You saying that the function de_min() is broken and nobody cares
about fixing it? I checked and found that nth() is used 44 times in 22
functions (in main/optim, main/vrml and extra/tk_octave) using the
function nth().
Several functions in the 'optim' package will no longer work with O
Carlo de Falco wrote:
> 2010/5/17 Alois Schlögl :
>> Jaroslav Hajek wrote:
>>> On Sun, May 16, 2010 at 8:08 PM, Alois Schlögl
>>> wrote:
Jaroslav Hajek wrote:
> On Fri, May 14, 2010 at 9:15 AM, Carlo de Falco
>
> wrote:
>> On 13 May 2010, at 23:00, Lukas Reichlin wrote:
>
> Lets look at another area: most OpenOffice users are using it on top of
> windows. And it does not hurt linux that they do so. It's similar here,
> toolboxes can be used with both. Why not using octave toolboxes on top
> of M ? It does no harm to octave if anyone does so.
>
>
Now this is a
> Lets look at another area: most OpenOffice users are using it on top of
> windows. And it does not hurt linux that they do so. It's similar here,
> toolboxes can be used with both. Why not using octave toolboxes on top
> of M ? It does no harm to octave if anyone does so.
>
>
Now this is a
2010/5/17 Alois Schlögl :
> Jaroslav Hajek wrote:
>>
>> On Sun, May 16, 2010 at 8:08 PM, Alois Schlögl
>> wrote:
>>>
>>> Jaroslav Hajek wrote:
On Fri, May 14, 2010 at 9:15 AM, Carlo de Falco
wrote:
>
> On 13 May 2010, at 23:00, Lukas Reichlin wrote:
>
>>> Certa
man, 17 05 2010 kl. 16:24 +0200, skrev Alois Schlögl:
> Søren Hauberg wrote:
> > Personally, I am not against the patch, but I wouldn't say that I am for
> > the patch either. I am not a fan of rewriting perfectly functional code
> > in order to help an automated Matlab converter.
>
>
> It's for
On Mon, May 17, 2010 at 11:11 AM, Judd Storrs wrote:
> I think the opposition is that your proposing rewriting octave code
> for the sole purpose of compatibility with a translator that targets
> octave.
I meant "targets Matlab". Oops.
--judd
---
On Mon, May 17, 2010 at 10:26 AM, Alois Schlögl
wrote:
> However, if there is no agreement that having
> "free toolboxes for matlab" is a worthwhile goal, it would expect similar
> opposition than trying to make the source code compatible.
I think the opposition is that your proposing rewriting o
Judd Storrs wrote:
> On Fri, May 7, 2010 at 3:38 PM, Alois Schlögl
> wrote:
>> - while ninner++ < maxinner
>> + while ninner < maxinner
>> +ninner = ninner + 1;
>
> If this is a problem that oct2mat cannot handle, possibly the octave
> language is just ill-suited to simple awk-based transf
Søren Hauberg wrote:
> tor, 13 05 2010 kl. 23:09 +0200, skrev Alois Schlögl:
>> Oct2mat has significantly improved. Most notable, support for the
>> following language elements as been added:
>>
>> - support for standalone ++, --,
>> - support of +=, -= etc operators,
>> - support of [blah](i
On Mon, May 17, 2010 at 2:49 PM, Alois Schlögl wrote:
> Jaroslav Hajek wrote:
>>
>> On Sun, May 16, 2010 at 8:08 PM, Alois Schlögl
>> wrote:
>>>
>>> Jaroslav Hajek wrote:
On Fri, May 14, 2010 at 9:15 AM, Carlo de Falco
wrote:
>
> On 13 May 2010, at 23:00, Lukas Reichl
Jaroslav Hajek wrote:
> On Sun, May 16, 2010 at 8:08 PM, Alois Schlögl
> wrote:
>> Jaroslav Hajek wrote:
>>> On Fri, May 14, 2010 at 9:15 AM, Carlo de Falco
>>> wrote:
On 13 May 2010, at 23:00, Lukas Reichlin wrote:
>> Certainly. But at this event, only Windows machines were availa
On 16 May 2010, at 20:08, Alois Schlögl wrote:
> What is your point here ? Some people are not as good in coding as
> others, the function this student wrote is still useful. What does it
> say about the performance of Octave vs. M ? Zero, Nil, Nothing.
Matlab has a feature called JIT (short for
On Fri, May 7, 2010 at 3:38 PM, Alois Schlögl wrote:
> - while ninner++ < maxinner
> + while ninner < maxinner
> + ninner = ninner + 1;
If this is a problem that oct2mat cannot handle, possibly the octave
language is just ill-suited to simple awk-based transformations?
If we stick strictly
On Sun, May 16, 2010 at 8:08 PM, Alois Schlögl wrote:
> Jaroslav Hajek wrote:
>>
>> On Fri, May 14, 2010 at 9:15 AM, Carlo de Falco
>> wrote:
>>>
>>> On 13 May 2010, at 23:00, Lukas Reichlin wrote:
>>>
> Certainly. But at this event, only Windows machines were available
> and
> Matlab
Jaroslav Hajek wrote:
> On Fri, May 14, 2010 at 9:15 AM, Carlo de Falco
> wrote:
>> On 13 May 2010, at 23:00, Lukas Reichlin wrote:
>>
Certainly. But at this event, only Windows machines were available
and
Matlab was already pre-installed. I had little options
about the setup.
On Fri, May 14, 2010 at 12:42:04AM -0700, Søren Hauberg wrote:
> tor, 13 05 2010 kl. 23:09 +0200, skrev Alois Schlögl:
> > (i) n(k)+=1; is preferred over n(k)++ for two reasons
> >
> > 1) the former is faster
> > octave:36> N=1e6;
> > octave:37> tic;
Carlo de Falco wrote:
>
> On 13 May 2010, at 23:00, Lukas Reichlin wrote:
>
>>> Certainly. But at this event, only Windows machines were available and
>>> Matlab was already pre-installed. I had little options
>>> about the setup. (and i do not want to say it loud, but M is still
>>> faster, [1].
tor, 13 05 2010 kl. 23:09 +0200, skrev Alois Schlögl:
> Oct2mat has significantly improved. Most notable, support for the
> following language elements as been added:
>
> - support for standalone ++, --,
> - support of +=, -= etc operators,
> - support of [blah](ix), fun(a)(ix)
> - do...un
On Fri, May 14, 2010 at 9:15 AM, Carlo de Falco wrote:
>
> On 13 May 2010, at 23:00, Lukas Reichlin wrote:
>
>>> Certainly. But at this event, only Windows machines were available
>>> and
>>> Matlab was already pre-installed. I had little options
>>> about the setup. (and i do not want to say it l
On 13 May 2010, at 23:00, Lukas Reichlin wrote:
>> Certainly. But at this event, only Windows machines were available
>> and
>> Matlab was already pre-installed. I had little options
>> about the setup. (and i do not want to say it loud, but M is still
>> faster, [1]. Admittingly, Octave has im
Oct2mat has significantly improved. Most notable, support for the
following language elements as been added:
- support for standalone ++, --,
- support of +=, -= etc operators,
- support of [blah](ix), fun(a)(ix)
- do...until,
- multiple assignments like a=b=c=d
- variable names starting wi
On 13.05.2010, at 21:23, Alois Schlögl wrote:
> Lukas,
>
>
> of course it is desirable to have a perfect solution. Until this goal is
> reached, Oct2mat is a great help and readly available for those who have
> the need of free toolboxes for matlab. And its not that nobody does the
> manual ch
Lukas Reichlin wrote:
>> Lukas,
>>
>>
>> thanks for your comments. I'm not sure I understand your comment on
>> "those automated changes just mess things up". The point of the
>> patch is that in some cases its better to use a manual change in
>> the source code, rather than applying an automate
> Lukas,
>
>
> thanks for your comments. I'm not sure I understand your comment on
> "those automated changes just mess things up". The point of the patch is
> that in some cases its better to use a manual change in the source code,
> rather than applying an automated script.
IMO it doesn't m
On Fri, May 07, 2010 at 09:38:49PM +0200, Alois Schlögl wrote:
> Olaf Till wrote:
> > On Thu, May 06, 2010 at 01:35:31PM -0700, Søren Hauberg wrote:
> >> tor, 06 05 2010 kl. 22:24 +0200, skrev Alois Schlögl:
> >>> After looking further into the problem of converting octave code into
> >>> a
> >>>
Lukas Reichlin wrote:
> On 06.05.2010, at 22:24, Alois Schlögl wrote:
>
>> After looking further into the problem of converting octave code
>> into a matlab compatible syntax, I concluded that in some cases it
>> is easiest way to make the source code compatible. In some cases,
>> there is just no
Olaf Till wrote:
> On Thu, May 06, 2010 at 01:35:31PM -0700, Søren Hauberg wrote:
>> tor, 06 05 2010 kl. 22:24 +0200, skrev Alois Schlögl:
>>> After looking further into the problem of converting octave code into
>>> a
>>> matlab compatible syntax, I concluded that in some cases it is
>>> easiest
On Fri, May 7, 2010 at 4:08 PM, Alois Schlögl wrote:
> Jaroslav Hajek wrote:
>>
>> On Thu, May 6, 2010 at 10:24 PM, Alois Schlögl
>> wrote:
>>>
>>> After looking further into the problem of converting octave code into a
>>> matlab compatible syntax, I concluded that in some cases it is easiest
>>
Jaroslav Hajek wrote:
> On Thu, May 6, 2010 at 10:24 PM, Alois Schlögl
> wrote:
>> After looking further into the problem of converting octave code into a
>> matlab compatible syntax, I concluded that in some cases it is easiest way
>> to make the source code compatible. In some cases, there is j
On 06.05.2010, at 22:24, Alois Schlögl wrote:
>
> After looking further into the problem of converting octave code into a
> matlab compatible syntax, I concluded that in some cases it is easiest way to
> make the source code compatible. In some cases, there is just no way to make
> an automate
On Thu, May 6, 2010 at 10:24 PM, Alois Schlögl wrote:
>
> After looking further into the problem of converting octave code into a
> matlab compatible syntax, I concluded that in some cases it is easiest way
> to make the source code compatible. In some cases, there is just no way to
> make an auto
On Thu, May 06, 2010 at 01:35:31PM -0700, Søren Hauberg wrote:
> tor, 06 05 2010 kl. 22:24 +0200, skrev Alois Schlögl:
> > After looking further into the problem of converting octave code into
> > a
> > matlab compatible syntax, I concluded that in some cases it is
> > easiest
> > way to make the
tor, 06 05 2010 kl. 22:24 +0200, skrev Alois Schlögl:
> After looking further into the problem of converting octave code into
> a
> matlab compatible syntax, I concluded that in some cases it is
> easiest
> way to make the source code compatible. In some cases, there is just
> no
> way to make a
34 matches
Mail list logo
