Support for N-dimensional arrays almost done

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Support for N-dimensional arrays almost done

Urathai
Hi!

I have almost finished the support for N-dimensional arrays in the
interval package. On my blog post last week [1] I wrote about the
current status. Since then I have also updated the coding style for all
m-files that were left.

So the things that are left are package documentation, which can be
added later if needed, and testing. Also some minor things like updating
the NEWS-file and most likely some other things as well that I'm
forgetting, or don't know, about.

Best regards,
Joel Dahne


[1] https://gsocinterval.blogspot.se/2017/07/ahead-of-timeline.html

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for N-dimensional arrays almost done

Oliver Heimlich
Hi Joel,

On 20.07.2017 17:37, Joel Dahne wrote:
> I have almost finished the support for N-dimensional arrays in the
> interval package. On my blog post last week [1] I wrote about the
> current status. Since then I have also updated the coding style for all
> m-files that were left.

> [1] https://gsocinterval.blogspot.se/2017/07/ahead-of-timeline.html

thank you very much for your great work so far.  It's hard for me to
keep pace with reviewing and merging your changes.  Fortunately, this
doesn't spoil your progress.  ;-)


Some small hints on your latest changes:

The last two examples in [2] should be reformatted in texinfo style: The
input lines need no prompt (>), and the result lines should be marked
with @result{}.

You disabled a doctest [3] in the manual.  It used to work in doctest
0.4.1, but no longer works in doctest 0.5.0.  The cause is: texinfo
examples without any output no longer get executed by default.  So,
doctest skips the first example block.  Consequently, the second block
fails.  It can be fixed with the following directive:

@c doctest: -TEXINFO_SKIP_BLOCKS_WO_OUTPUT


Regarding the unit tests: I'll put a little bit more work into the
Makefile and add complete support for the new ITF1788 test data during
all make targets, e. g., “make run”.  The aim is that we can eventually
get rid of the generated test/*.tst files (or
build/octave/native/interval/*.tst files in the package development
workspace).  For the user it makes package testing more straight forward
since you can simply test the function that you want to test and don't
have to execute an extra test suite.  If you want, you can spread use of
itl.mat among the other methods and add ND array test by reshaping the
test data.


Regarding bonus topics that you could follow after having finished the
work on ND arrays:

 - Improve plotting [4] by adding support for more functions (plotyy,
semilogx/y, loglog, and others that make sense) or by adding support for
plotting options (line style, marker style, …).

 - Implement new interval arithmetic functions (some rough ideas in the
wiki [5]).

 - Also I like your idea to work on Taylor arithmetic, since it is
closely related.


Best
Oliver


[2]
https://sourceforge.net/u/urathai/octave/ci/76431745772f12936e11f8f7b8329eab98c53b62/

[3]
https://sourceforge.net/u/urathai/octave/ci/c078807c6b32142a96e3441a4bea474aebaa23bd/

[4]
https://www.gnu.org/software/octave/doc/interpreter/High_002dLevel-Plotting.html

[5] http://wiki.octave.org/Interval_package#Development_status

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for N-dimensional arrays almost done

Urathai
Hi Oliver,

Oliver Heimlich writes:

> thank you very much for your great work so far.  It's hard for me to
> keep pace with reviewing and merging your changes.  Fortunately, this
> doesn't spoil your progress.  ;-)

I have full understanding for that it takes some time for you to review
and merge them. I have no problem continuing with the rest of my work so
you don't have to feel rushed. Just let me know when you encounter
some problem or some thing odd and I will try to fix it!

> Some small hints on your latest changes:
>
> The last two examples in [2] should be reformatted in texinfo style: The
> input lines need no prompt (>), and the result lines should be marked
> with @result{}.
>
> You disabled a doctest [3] in the manual.  It used to work in doctest
> 0.4.1, but no longer works in doctest 0.5.0.  The cause is: texinfo
> examples without any output no longer get executed by default.  So,
> doctest skips the first example block.  Consequently, the second block
> fails.  It can be fixed with the following directive:
>
> @c doctest: -TEXINFO_SKIP_BLOCKS_WO_OUTPUT

I have fixed both of them! There is one more test that always fails for
me

doc/chapter/examples.texinfo ........................... FAIL    1/15

   >> f = @(x) sqrt (x) + (x + 1) .* cos (x);
    pkg load symbolic
    df = function_handle (diff (formula (f (sym ("x")))))

      expected:    df = @(x) -(x + 1) .* sin (x) + cos (x) + 1 ./ (2 .* sqrt (x))

      got     : df =

@(x) -(x + 1) .* sin (x) + cos (x) + 1 ./ (2 * sqrt (x))

It seems like that there is only a problem with the formatting but I
have not been able to fix it. Does it fail for you to, and if so should
I add a SKIP for it?

>
>
> Regarding the unit tests: I'll put a little bit more work into the
> Makefile and add complete support for the new ITF1788 test data during
> all make targets, e. g., “make run”.  The aim is that we can eventually
> get rid of the generated test/*.tst files (or
> build/octave/native/interval/*.tst files in the package development
> workspace).  For the user it makes package testing more straight forward
> since you can simply test the function that you want to test and don't
> have to execute an extra test suite.  If you want, you can spread use of
> itl.mat among the other methods and add ND array test by reshaping the
> test data.

I'm not sure I follow you here. You want to get rid of the test/*.tst
files, where should the test be stored then? Is the goal to be able to
use Octaves test-command to perform all tests (thus making it easy to
test only one function)? ITF1788 will supply the testing data, where
will we reshape the data, in ITF1788 or in the interval packages Makefile?

> Regarding bonus topics that you could follow after having finished the
> work on ND arrays:
>
>  - Improve plotting [4] by adding support for more functions (plotyy,
> semilogx/y, loglog, and others that make sense) or by adding support for
> plotting options (line style, marker style, …).
>
>  - Implement new interval arithmetic functions (some rough ideas in the
> wiki [5]).
>
>  - Also I like your idea to work on Taylor arithmetic, since it is
> closely related.

I have started to work on a package to Taylor arithmetic. At the moment
I'm using the same repository as during the spring [1]. Most likely I
will later have some question regarding how to handle a new package in
Octave but at the moment I'm just trying to get it to work.

[1]
https://github.com/Urathai/octave-taylor-POC
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for N-dimensional arrays almost done

Oliver Heimlich
Hi Joel,

On 25.07.2017 10:59, Joel Dahne wrote:

> There is one more test that always fails for me
>
> doc/chapter/examples.texinfo ........................... FAIL    1/15
>
>    >> f = @(x) sqrt (x) + (x + 1) .* cos (x);
>     pkg load symbolic
>     df = function_handle (diff (formula (f (sym ("x")))))
>
>       expected:    df = @(x) -(x + 1) .* sin (x) + cos (x) + 1 ./ (2 .* sqrt (x))
>
>       got     : df =
>
> @(x) -(x + 1) .* sin (x) + cos (x) + 1 ./ (2 * sqrt (x))
>
> It seems like that there is only a problem with the formatting but I
> have not been able to fix it. Does it fail for you to, and if so should
> I add a SKIP for it?

The formatting has changed in the symbolic package since I have written
this example. I am going to fix the formatting of the example to match
the new version.

> Oliver Heimlich writes:
>> Regarding the unit tests: I'll put a little bit more work into the
>> Makefile and add complete support for the new ITF1788 test data during
>> all make targets, e. g., “make run”.  The aim is that we can eventually
>> get rid of the generated test/*.tst files (or
>> build/octave/native/interval/*.tst files in the package development
>> workspace).  For the user it makes package testing more straight forward
>> since you can simply test the function that you want to test and don't
>> have to execute an extra test suite.  If you want, you can spread use of
>> itl.mat among the other methods and add ND array test by reshaping the
>> test data.
>
> I'm not sure I follow you here. You want to get rid of the test/*.tst
> files, where should the test be stored then? Is the goal to be able to
> use Octaves test-command to perform all tests (thus making it easy to
> test only one function)? ITF1788 will supply the testing data, where
> will we reshape the data, in ITF1788 or in the interval packages Makefile?

I am currently working on this. I hope to finish migration this night.
You can have a peek in [6], I am going to push other functions later.
The test data will be stored in a .mat file. The tests are performed
during “test <functioname>”, which has to load its part of the test data
from the .mat file.

Shaping the test data into the .mat file has already been implemented.
The testcases are stored as cell arrays. It is possible to either
iterate over the cell array (for scalar tests) or cat the cell array
(for vector tests). I have already prepared %!test blocks to do this.

Your job would be to add one or more %!test blocks, which reshape the
data into ND arrays (you may discard some test cases to get correct
dimensions).

[6]
https://sourceforge.net/p/octave/interval/ci/f35e6c4964256c14b87d1aa315dd60a6ad38e52b/tree/inst/@infsup/plus.m#l80


>> Regarding bonus topics that you could follow after having finished the
>> work on ND arrays:
>>
>>  - Improve plotting [4] by adding support for more functions (plotyy,
>> semilogx/y, loglog, and others that make sense) or by adding support for
>> plotting options (line style, marker style, …).
>>
>>  - Implement new interval arithmetic functions (some rough ideas in the
>> wiki [5]).
>>
>>  - Also I like your idea to work on Taylor arithmetic, since it is
>> closely related.
>
> I have started to work on a package to Taylor arithmetic. At the moment
> I'm using the same repository as during the spring [1]. Most likely I
> will later have some question regarding how to handle a new package in
> Octave but at the moment I'm just trying to get it to work.

Nice, please don't forget to also assign copyright to original authors
at the beginning of files when you copy from existing packages.

>
> [1]
> https://github.com/Urathai/octave-taylor-POC
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for N-dimensional arrays almost done

Oliver Heimlich
On 27.07.2017 23:49, Oliver Heimlich wrote:

> On 25.07.2017 10:59, Joel Dahne wrote:
>> Oliver Heimlich writes:
>>> Regarding the unit tests: I'll put a little bit more work into the
>>> Makefile and add complete support for the new ITF1788 test data during
>>> all make targets, e. g., “make run”.  The aim is that we can eventually
>>> get rid of the generated test/*.tst files (or
>>> build/octave/native/interval/*.tst files in the package development
>>> workspace).  For the user it makes package testing more straight forward
>>> since you can simply test the function that you want to test and don't
>>> have to execute an extra test suite.  If you want, you can spread use of
>>> itl.mat among the other methods and add ND array test by reshaping the
>>> test data.
>>
>> I'm not sure I follow you here. You want to get rid of the test/*.tst
>> files, where should the test be stored then? Is the goal to be able to
>> use Octaves test-command to perform all tests (thus making it easy to
>> test only one function)? ITF1788 will supply the testing data, where
>> will we reshape the data, in ITF1788 or in the interval packages Makefile?
>
> I am currently working on this. I hope to finish migration this night.
> You can have a peek in [6], I am going to push other functions later.
> The test data will be stored in a .mat file. The tests are performed
> during “test <functioname>”, which has to load its part of the test data
> from the .mat file.
>
> Shaping the test data into the .mat file has already been implemented.
> The testcases are stored as cell arrays. It is possible to either
> iterate over the cell array (for scalar tests) or cat the cell array
> (for vector tests). I have already prepared %!test blocks to do this.
>
> Your job would be to add one or more %!test blocks, which reshape the
> data into ND arrays (you may discard some test cases to get correct
> dimensions).
>
> [6]
> https://sourceforge.net/p/octave/interval/ci/f35e6c4964256c14b87d1aa315dd60a6ad38e52b/tree/inst/@infsup/plus.m#l80

So far, I have only finished the bare interval tests, see revision
d56e0d42c458. There are some failing vectorized tests, which I have
marked as xtest.

Oliver

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for N-dimensional arrays almost done

Oliver Heimlich
On 28.07.2017 01:26, Oliver Heimlich wrote:

> On 27.07.2017 23:49, Oliver Heimlich wrote:
>> On 25.07.2017 10:59, Joel Dahne wrote:
>>> Oliver Heimlich writes:
>>>> Regarding the unit tests: I'll put a little bit more work into the
>>>> Makefile and add complete support for the new ITF1788 test data during
>>>> all make targets, e. g., “make run”.  The aim is that we can eventually
>>>> get rid of the generated test/*.tst files (or
>>>> build/octave/native/interval/*.tst files in the package development
>>>> workspace).  For the user it makes package testing more straight forward
>>>> since you can simply test the function that you want to test and don't
>>>> have to execute an extra test suite.  If you want, you can spread use of
>>>> itl.mat among the other methods and add ND array test by reshaping the
>>>> test data.
>>>
>>> I'm not sure I follow you here. You want to get rid of the test/*.tst
>>> files, where should the test be stored then? Is the goal to be able to
>>> use Octaves test-command to perform all tests (thus making it easy to
>>> test only one function)? ITF1788 will supply the testing data, where
>>> will we reshape the data, in ITF1788 or in the interval packages Makefile?
>>
>> I am currently working on this. I hope to finish migration this night.
>> You can have a peek in [6], I am going to push other functions later.
>> The test data will be stored in a .mat file. The tests are performed
>> during “test <functioname>”, which has to load its part of the test data
>> from the .mat file.
>>
>> Shaping the test data into the .mat file has already been implemented.
>> The testcases are stored as cell arrays. It is possible to either
>> iterate over the cell array (for scalar tests) or cat the cell array
>> (for vector tests). I have already prepared %!test blocks to do this.
>>
>> Your job would be to add one or more %!test blocks, which reshape the
>> data into ND arrays (you may discard some test cases to get correct
>> dimensions).
>>
>> [6]
>> https://sourceforge.net/p/octave/interval/ci/f35e6c4964256c14b87d1aa315dd60a6ad38e52b/tree/inst/@infsup/plus.m#l80
>
> So far, I have only finished the bare interval tests, see revision
> d56e0d42c458. There are some failing vectorized tests, which I have
> marked as xtest.

I have completed my refactoring of the unit tests. I didn't add checks
for ND arrays. The following functions currently have issues when
evaluated on vectors:
overlap, nthroot, pow, pownrev, powrev2

Do you want to look into this? pownrev and nthroot don't support vectors
for all parameters yet.

I have partially updated the NEWS.texinfo file.  We have some
improvements that are not strictly backwards-compatible. And, given the
great new support for ND arrays, this is a good opportunity to raise the
major version.  Please add a few lines at the beginning of NEWS.texinfo
and advertise the results of your work.

Best
Oliver

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for N-dimensional arrays almost done

Urathai

Oliver Heimlich writes:

> On 28.07.2017 01:26, Oliver Heimlich wrote:
>> On 27.07.2017 23:49, Oliver Heimlich wrote:
>>> On 25.07.2017 10:59, Joel Dahne wrote:
>>>> Oliver Heimlich writes:
>>>>> Regarding the unit tests: I'll put a little bit more work into the
>>>>> Makefile and add complete support for the new ITF1788 test data during
>>>>> all make targets, e. g., “make run”.  The aim is that we can eventually
>>>>> get rid of the generated test/*.tst files (or
>>>>> build/octave/native/interval/*.tst files in the package development
>>>>> workspace).  For the user it makes package testing more straight forward
>>>>> since you can simply test the function that you want to test and don't
>>>>> have to execute an extra test suite.  If you want, you can spread use of
>>>>> itl.mat among the other methods and add ND array test by reshaping the
>>>>> test data.
>>>>
>>>> I'm not sure I follow you here. You want to get rid of the test/*.tst
>>>> files, where should the test be stored then? Is the goal to be able to
>>>> use Octaves test-command to perform all tests (thus making it easy to
>>>> test only one function)? ITF1788 will supply the testing data, where
>>>> will we reshape the data, in ITF1788 or in the interval packages Makefile?
>>>
>>> I am currently working on this. I hope to finish migration this night.
>>> You can have a peek in [6], I am going to push other functions later.
>>> The test data will be stored in a .mat file. The tests are performed
>>> during “test <functioname>”, which has to load its part of the test data
>>> from the .mat file.
>>>
>>> Shaping the test data into the .mat file has already been implemented.
>>> The testcases are stored as cell arrays. It is possible to either
>>> iterate over the cell array (for scalar tests) or cat the cell array
>>> (for vector tests). I have already prepared %!test blocks to do this.
>>>
>>> Your job would be to add one or more %!test blocks, which reshape the
>>> data into ND arrays (you may discard some test cases to get correct
>>> dimensions).
>>>
>>> [6]
>>> https://sourceforge.net/p/octave/interval/ci/f35e6c4964256c14b87d1aa315dd60a6ad38e52b/tree/inst/@infsup/plus.m#l80
>>
>> So far, I have only finished the bare interval tests, see revision
>> d56e0d42c458. There are some failing vectorized tests, which I have
>> marked as xtest.
>
> I have completed my refactoring of the unit tests. I didn't add checks
> for ND arrays. The following functions currently have issues when
> evaluated on vectors:
> overlap, nthroot, pow, pownrev, powrev2
>
> Do you want to look into this? pownrev and nthroot don't support vectors
> for all parameters yet.

I can take a look at this. Both add tests for ND arrays and see if I can
fix the functions that have issues.

> I have partially updated the NEWS.texinfo file.  We have some
> improvements that are not strictly backwards-compatible. And, given the
> great new support for ND arrays, this is a good opportunity to raise the
> major version.  Please add a few lines at the beginning of NEWS.texinfo
> and advertise the results of your work.

Will do!

Best,
Joel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for N-dimensional arrays almost done

Urathai
In reply to this post by Oliver Heimlich
Hi Oliver

Oliver Heimlich writes:

>> There is one more test that always fails for me
>>
>> doc/chapter/examples.texinfo ........................... FAIL    1/15
>>
>>    >> f = @(x) sqrt (x) + (x + 1) .* cos (x);
>>     pkg load symbolic
>>     df = function_handle (diff (formula (f (sym ("x")))))
>>
>>       expected:    df = @(x) -(x + 1) .* sin (x) + cos (x) + 1 ./ (2 .* sqrt (x))
>>
>>       got     : df =
>>
>> @(x) -(x + 1) .* sin (x) + cos (x) + 1 ./ (2 * sqrt (x))
>>
>> It seems like that there is only a problem with the formatting but I
>> have not been able to fix it. Does it fail for you to, and if so should
>> I add a SKIP for it?
>
> The formatting has changed in the symbolic package since I have written
> this example. I am going to fix the formatting of the example to match
> the new version.

The test still fails for me with the new patch. I think texinfo (or
doctest) has trouble with multiple newlines. Tried to add specific
newlines with @NL (where NL is a newline character) but it still did not
work. For reference I'm using symbolic 2.6.0.

>> Oliver Heimlich writes:
>>> Regarding the unit tests: I'll put a little bit more work into the
>>> Makefile and add complete support for the new ITF1788 test data during
>>> all make targets, e. g., “make run”.  The aim is that we can eventually
>>> get rid of the generated test/*.tst files (or
>>> build/octave/native/interval/*.tst files in the package development
>>> workspace).  For the user it makes package testing more straight forward
>>> since you can simply test the function that you want to test and don't
>>> have to execute an extra test suite.  If you want, you can spread use of
>>> itl.mat among the other methods and add ND array test by reshaping the
>>> test data.
>>
>> I'm not sure I follow you here. You want to get rid of the test/*.tst
>> files, where should the test be stored then? Is the goal to be able to
>> use Octaves test-command to perform all tests (thus making it easy to
>> test only one function)? ITF1788 will supply the testing data, where
>> will we reshape the data, in ITF1788 or in the interval packages Makefile?
>
> I am currently working on this. I hope to finish migration this night.
> You can have a peek in [6], I am going to push other functions later.
> The test data will be stored in a .mat file. The tests are performed
> during “test <functioname>”, which has to load its part of the test data
> from the .mat file.
>
> Shaping the test data into the .mat file has already been implemented.
> The testcases are stored as cell arrays. It is possible to either
> iterate over the cell array (for scalar tests) or cat the cell array
> (for vector tests). I have already prepared %!test blocks to do this.
>
> Your job would be to add one or more %!test blocks, which reshape the
> data into ND arrays (you may discard some test cases to get correct
> dimensions).
>
> [6]
> https://sourceforge.net/p/octave/interval/ci/f35e6c4964256c14b87d1aa315dd60a6ad38e52b/tree/inst/@infsup/plus.m#l80

Running 'make run' does not work for me with the current tip. I get the
error

Regenerating interval test library (build/inst/test/itl.mat) ...
  build/octave/dictionary/interval-dictionary/abs_rev.tst
error: wrong type argument 'cell'
error: source: FILE must be a string

Changing line 355 in the Makefile from

--eval 'for file = strsplit ("$^"), printf ("  %s\n", file{:}); source
  (file); endfor;' \

to

--eval 'for file = strsplit ("$^"), printf ("  %s\n", file{:}); source
  (file{:); endfor;' \

fixes it for me.

Finally I have a question. Up until recently I have been working on my
fork of the interval package and you have been merging changes from time
to time. Now you have made changes to the original repository that I
would need to merge to mine. What is the simplest way to accomplish
that? On sourceforge I have a "request merge" button which I guess is
for if I want you to merge my changes, but I can find no way to merge
your changes to my repository.

Best,
Joel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for N-dimensional arrays almost done

Oliver Heimlich
Hi,

sorry for top posting. I am on the road.

I can't use the latest symbolic package. I am still on Debian Jessie. The new version of symbolic seems to produce different output for the scalar prefix 2 (spot the difference in .* vs. *).

Regarding "make run" your fix makes sense. Maybe my Octave is outdated and supports the old syntax as well (regression?).

To continue your work it makes sense to 'pull' and 'update' from the original repository (in hg speak). You should be able to do that in your local hg client.

Oliver


  Ursprüngliche Nachricht  
Von: [hidden email]
Gesendet: 31. Juli 2017 9:43 vorm.
An: [hidden email]
Antworten: [hidden email]
Cc: [hidden email]; [hidden email]
Betreff: Re: Support for N-dimensional arrays almost done

Hi Oliver

Oliver Heimlich writes:

>> There is one more test that always fails for me
>>
>> doc/chapter/examples.texinfo ........................... FAIL    1/15
>>
>>    >> f = @(x) sqrt (x) + (x + 1) .* cos (x);
>>     pkg load symbolic
>>     df = function_handle (diff (formula (f (sym ("x")))))
>>
>>       expected:    df = @(x) -(x + 1) .* sin (x) + cos (x) + 1 ./ (2 .* sqrt (x))
>>
>>       got     : df =
>>
>> @(x) -(x + 1) .* sin (x) + cos (x) + 1 ./ (2 * sqrt (x))
>>
>> It seems like that there is only a problem with the formatting but I
>> have not been able to fix it. Does it fail for you to, and if so should
>> I add a SKIP for it?
>
> The formatting has changed in the symbolic package since I have written
> this example. I am going to fix the formatting of the example to match
> the new version.

The test still fails for me with the new patch. I think texinfo (or
doctest) has trouble with multiple newlines. Tried to add specific
newlines with @NL (where NL is a newline character) but it still did not
work. For reference I'm using symbolic 2.6.0.

>> Oliver Heimlich writes:
>>> Regarding the unit tests: I'll put a little bit more work into the
>>> Makefile and add complete support for the new ITF1788 test data during
>>> all make targets, e. g., “make run”.  The aim is that we can eventually
>>> get rid of the generated test/*.tst files (or
>>> build/octave/native/interval/*.tst files in the package development
>>> workspace).  For the user it makes package testing more straight forward
>>> since you can simply test the function that you want to test and don't
>>> have to execute an extra test suite.  If you want, you can spread use of
>>> itl.mat among the other methods and add ND array test by reshaping the
>>> test data.
>>
>> I'm not sure I follow you here. You want to get rid of the test/*.tst
>> files, where should the test be stored then? Is the goal to be able to
>> use Octaves test-command to perform all tests (thus making it easy to
>> test only one function)? ITF1788 will supply the testing data, where
>> will we reshape the data, in ITF1788 or in the interval packages Makefile?
>
> I am currently working on this. I hope to finish migration this night.
> You can have a peek in [6], I am going to push other functions later.
> The test data will be stored in a .mat file. The tests are performed
> during “test <functioname>”, which has to load its part of the test data
> from the .mat file.
>
> Shaping the test data into the .mat file has already been implemented.
> The testcases are stored as cell arrays. It is possible to either
> iterate over the cell array (for scalar tests) or cat the cell array
> (for vector tests). I have already prepared %!test blocks to do this.
>
> Your job would be to add one or more %!test blocks, which reshape the
> data into ND arrays (you may discard some test cases to get correct
> dimensions).
>
> [6]
> https://sourceforge.net/p/octave/interval/ci/f35e6c4964256c14b87d1aa315dd60a6ad38e52b/tree/inst/@infsup/plus.m#l80

Running 'make run' does not work for me with the current tip. I get the
error

Regenerating interval test library (build/inst/test/itl.mat) ...
  build/octave/dictionary/interval-dictionary/abs_rev.tst
error: wrong type argument 'cell'
error: source: FILE must be a string

Changing line 355 in the Makefile from

--eval 'for file = strsplit ("$^"), printf ("  %s\n", file{:}); source
  (file); endfor;' \

to

--eval 'for file = strsplit ("$^"), printf ("  %s\n", file{:}); source
  (file{:); endfor;' \

fixes it for me.

Finally I have a question. Up until recently I have been working on my
fork of the interval package and you have been merging changes from time
to time. Now you have made changes to the original repository that I
would need to merge to mine. What is the simplest way to accomplish
that? On sourceforge I have a "request merge" button which I guess is
for if I want you to merge my changes, but I can find no way to merge
your changes to my repository.

Best,
Joel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for N-dimensional arrays almost done

Urathai
In reply to this post by Urathai
Hi,

Thanks for the quick reply. The merge went well! I completely missed the
.* vs *, was to focused on the newline, changing that it works. But
since there are two active version out there I'm not sure which one we
should use, I will leave it as it is for now.

Joel

Oliver Heimlich writes:

> Hi,
>
> sorry for top posting. I am on the road.
>
> I can't use the latest symbolic package. I am still on Debian Jessie. The new version of symbolic seems to produce different output for the scalar prefix 2 (spot the difference in .* vs. *).
>
> Regarding "make run" your fix makes sense. Maybe my Octave is outdated and supports the old syntax as well (regression?).
>
> To continue your work it makes sense to 'pull' and 'update' from the original repository (in hg speak). You should be able to do that in your local hg client.
>
> Oliver
>
>
>  Ursprüngliche Nachricht
> Von: [hidden email]
> Gesendet: 31. Juli 2017 9:43 vorm.
> An: [hidden email]
> Antworten: [hidden email]
> Cc: [hidden email]; [hidden email]
> Betreff: Re: Support for N-dimensional arrays almost done
>
> Hi Oliver
>
> Oliver Heimlich writes:
>
>>> There is one more test that always fails for me
>>>
>>> doc/chapter/examples.texinfo ........................... FAIL 1/15
>>>
>>> >> f = @(x) sqrt (x) + (x + 1) .* cos (x);
>>> pkg load symbolic
>>> df = function_handle (diff (formula (f (sym ("x")))))
>>>
>>> expected: df = @(x) -(x + 1) .* sin (x) + cos (x) + 1 ./ (2 .* sqrt (x))
>>>
>>> got : df =
>>>
>>> @(x) -(x + 1) .* sin (x) + cos (x) + 1 ./ (2 * sqrt (x))
>>>
>>> It seems like that there is only a problem with the formatting but I
>>> have not been able to fix it. Does it fail for you to, and if so should
>>> I add a SKIP for it?
>>
>> The formatting has changed in the symbolic package since I have written
>> this example. I am going to fix the formatting of the example to match
>> the new version.
>
> The test still fails for me with the new patch. I think texinfo (or
> doctest) has trouble with multiple newlines. Tried to add specific
> newlines with @NL (where NL is a newline character) but it still did not
> work. For reference I'm using symbolic 2.6.0.
>
>>> Oliver Heimlich writes:
>>>> Regarding the unit tests: I'll put a little bit more work into the
>>>> Makefile and add complete support for the new ITF1788 test data during
>>>> all make targets, e. g., “make run”. The aim is that we can eventually
>>>> get rid of the generated test/*.tst files (or
>>>> build/octave/native/interval/*.tst files in the package development
>>>> workspace). For the user it makes package testing more straight forward
>>>> since you can simply test the function that you want to test and don't
>>>> have to execute an extra test suite. If you want, you can spread use of
>>>> itl.mat among the other methods and add ND array test by reshaping the
>>>> test data.
>>>
>>> I'm not sure I follow you here. You want to get rid of the test/*.tst
>>> files, where should the test be stored then? Is the goal to be able to
>>> use Octaves test-command to perform all tests (thus making it easy to
>>> test only one function)? ITF1788 will supply the testing data, where
>>> will we reshape the data, in ITF1788 or in the interval packages Makefile?
>>
>> I am currently working on this. I hope to finish migration this night.
>> You can have a peek in [6], I am going to push other functions later.
>> The test data will be stored in a .mat file. The tests are performed
>> during “test <functioname>”, which has to load its part of the test data
>> from the .mat file.
>>
>> Shaping the test data into the .mat file has already been implemented.
>> The testcases are stored as cell arrays. It is possible to either
>> iterate over the cell array (for scalar tests) or cat the cell array
>> (for vector tests). I have already prepared %!test blocks to do this.
>>
>> Your job would be to add one or more %!test blocks, which reshape the
>> data into ND arrays (you may discard some test cases to get correct
>> dimensions).
>>
>> [6]
>> https://sourceforge.net/p/octave/interval/ci/f35e6c4964256c14b87d1aa315dd60a6ad38e52b/tree/inst/@infsup/plus.m#l80
>
> Running 'make run' does not work for me with the current tip. I get the
> error
>
> Regenerating interval test library (build/inst/test/itl.mat) ...
>  build/octave/dictionary/interval-dictionary/abs_rev.tst
> error: wrong type argument 'cell'
> error: source: FILE must be a string
>
> Changing line 355 in the Makefile from
>
> --eval 'for file = strsplit ("$^"), printf (" %s\n", file{:}); source
>  (file); endfor;' \
>
> to
>
> --eval 'for file = strsplit ("$^"), printf (" %s\n", file{:}); source
>  (file{:); endfor;' \
>
> fixes it for me.
>
> Finally I have a question. Up until recently I have been working on my
> fork of the interval package and you have been merging changes from time
> to time. Now you have made changes to the original repository that I
> would need to merge to mine. What is the simplest way to accomplish
> that? On sourceforge I have a "request merge" button which I guess is
> for if I want you to merge my changes, but I can find no way to merge
> your changes to my repository.
>
> Best,
> Joel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for N-dimensional arrays almost done

Colin Macdonald-2
On 2017-07-31 01:21 AM, Joel Dahne wrote:
> Hi,
>
> Thanks for the quick reply. The merge went well! I completely missed the
> .* vs *, was to focused on the newline, changing that it works. But
> since there are two active version out there I'm not sure which one we
> should use, I will leave it as it is for now.

Just FYI, "2*x.*y" is the current output from Symbolic for
"function_handle(2*x*y)".

This is a doctest right?  You can protect your test from old versions like:

## @example
## @c doctest: +SKIP_IF(compare_versions (sympref('version'), '2.5.0', '<'))
## ...
## @end example

(Note this needs latest doctest-0.5.0)

Background: old versions of Symbolic/SymPy used the Octave command
"vectorize" (which gives "2.*x.*y") but these days SymPy does the Octave
code generation for us.

Colin

Loading...