Implementing advanced scientific calculator.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Implementing advanced scientific calculator.

Dildar Sk
Like Matlab Octave is definitely for advanced scientific works.
So,I really feel urge for presence of scientific calculators(Obviously GUI)
like command editor,editor,variable editor.
I am going to give this proposal for GSoC.Expecting feedbacks.



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html


Reply | Threaded
Open this post in threaded view
|

Re: Implementing advanced scientific calculator.

Sergei Steshenko





________________________________
From: Dildar Sk <[hidden email]>
To: [hidden email]
Sent: Thursday, March 15, 2018 12:47 PM
Subject: Implementing advanced scientific calculator.



Like Matlab Octave is definitely for advanced scientific works.

So,I really feel urge for presence of scientific calculators(Obviously GUI)

like command editor,editor,variable editor.

I am going to give this proposal for GSoC.Expecting feedbacks.


-----

"Expecting feedbacks" - completely unnecessary.

Octave + text editor of your choice are quite sufficient. Besides that, have a look at http://www.jirka.org/genius.html .

The only case GUI is really necessary is modeling environment with blocks and connections between them. E.g.
http://www.scilab.org/scilab/features/xcos .

--Sergei.


Reply | Threaded
Open this post in threaded view
|

Re: Implementing advanced scientific calculator.

Sergei Steshenko





________________________________
From: Sergei Steshenko <[hidden email]>
To: Dildar Sk <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Thursday, March 15, 2018 11:26 PM
Subject: Re: Implementing advanced scientific calculator.








________________________________

From: Dildar Sk <[hidden email]>
To: [hidden email]
Sent: Thursday, March 15, 2018 12:47 PM
Subject: Implementing advanced scientific calculator.



Like Matlab Octave is definitely for advanced scientific works.

So,I really feel urge for presence of scientific calculators(Obviously GUI)

like command editor,editor,variable editor.

I am going to give this proposal for GSoC.Expecting feedbacks.


-----

"Expecting feedbacks" - completely unnecessary.

Octave + text editor of your choice are quite sufficient. Besides that, have a look at http://www.jirka.org/genius.html .

The only case GUI is really necessary is modeling environment with blocks and connections between them. E.g.
http://www.scilab.org/scilab/features/xcos .


--Sergei.

-------------------------------------


And have a look at http://andrejv.github.io/wxmaxima/ .

--Sergei.


Reply | Threaded
Open this post in threaded view
|

Re: Implementing advanced scientific calculator.

Dildar Sk
Sergei,
I wanted to ask how much is it feasible in GSoC.
Will it be even a good proposal?



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html


Reply | Threaded
Open this post in threaded view
|

Re: Implementing advanced scientific calculator.

Sergei Steshenko





________________________________
From: Dildar Sk <[hidden email]>
To: [hidden email]
Sent: Friday, March 16, 2018 4:44 PM
Subject: Re: Implementing advanced scientific calculator.



Sergei,
I wanted to ask how much is it feasible in GSoC.
Will it be even a good proposal?



--

Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html


----------------------------

"how much is it feasible in GSoC" - I have no idea.

"Will it be even a good proposal?" - IMO it's a bad proposal because it's waste of resources (of efforts of developers).

...

Several years ago Octave package system was conceptually broken. It probably still is.

If so, a probably useful task would to define first and maybe implement a new package system.

Another useful feature would be to write Octave to Julia ( https://julialang.org/ ) translator.

Also, there is an interesting library to convert Octave code into C++ : https://bitbucket.org/cyrille/cauchy . I haven't tried it yet. If it at least somehow works and demands improvement, improving it would be a great thing.

--Sergei.


Reply | Threaded
Open this post in threaded view
|

Re: Implementing advanced scientific calculator.

Sebastian Schöps
Dear Sergei,


Sergei Steshenko wrote

> Several years ago Octave package system was conceptually broken. It
> probably still is.
> If so, a probably useful task would to define first and maybe implement a
> new package system.
> Another useful feature would be to write Octave to Julia (
> https://julialang.org/ ) translator.
> Also, there is an interesting library to convert Octave code into C++ :
> https://bitbucket.org/cyrille/cauchy. I haven't tried it yet. If it at
> least somehow works and demands improvement, improving it would be a great
> thing.

the community has already created a website for this kind of recommendations
[1]. For example, it contains a project on the package system wich goes
beyond "it's broken, fix it". So, please add your proposals to [1] if you
like but if you do, then make sure that there is a mentor. By the way, I do
not see why it should be of interest for the Octave community to write a
translator from Octave to Julia?

Sebastian

[1] https://wiki.octave.org/Summer_of_Code_Project_Ideas.



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html


Reply | Threaded
Open this post in threaded view
|

Re: Implementing advanced scientific calculator.

avlas-2
In reply to this post by Sergei Steshenko
Didn't know about Cauchy. There's another project that does similarly: https://github.com/jonathf/matlab2cpp

--
Sent from phone

-------- Original Message --------
Subject: Re: Implementing advanced scientific calculator.
From: Sergei Steshenko
To: Dildar Sk ,[hidden email]
CC:






________________________________
From: Dildar Sk <[hidden email]>
To: [hidden email]
Sent: Friday, March 16, 2018 4:44 PM
Subject: Re: Implementing advanced scientific calculator.



Sergei,
I wanted to ask how much is it feasible in GSoC.
Will it be even a good proposal?



--

Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html


----------------------------

"how much is it feasible in GSoC" - I have no idea.

"Will it be even a good proposal?" - IMO it's a bad proposal because it's waste of resources (of efforts of developers).

...

Several years ago Octave package system was conceptually broken. It probably still is.

If so, a probably useful task would to define first and maybe implement a new package system.

Another useful feature would be to write Octave to Julia ( https://julialang.org/ ) translator.

Also, there is an interesting library to convert Octave code into C++ : https://bitbucket.org/cyrille/cauchy . I haven't tried it yet. If it at least somehow works and demands improvement, improving it would be a great thing.

--Sergei.




Reply | Threaded
Open this post in threaded view
|

Re: Implementing advanced scientific calculator.

Sergei Steshenko
In reply to this post by Sebastian Schöps





________________________________
From: Sebastian Schöps <[hidden email]>
To: [hidden email]
Sent: Friday, March 16, 2018 7:46 PM
Subject: Re: Implementing advanced scientific calculator.



Dear Sergei,


Sergei Steshenko wrote

> Several years ago Octave package system was conceptually broken. It
> probably still is.
> If so, a probably useful task would to define first and maybe implement a
> new package system.
> Another useful feature would be to write Octave to Julia (
> https://julialang.org/ ) translator.
> Also, there is an interesting library to convert Octave code into C++ :
> https://bitbucket.org/cyrille/cauchy. I haven't tried it yet. If it at
> least somehow works and demands improvement, improving it would be a great
> thing.

the community has already created a website for this kind of recommendations
[1]. For example, it contains a project on the package system wich goes
beyond "it's broken, fix it". So, please add your proposals to [1] if you
like but if you do, then make sure that there is a mentor. By the way, I do
not see why it should be of interest for the Octave community to write a
translator from Octave to Julia?

Sebastian

[1] https://wiki.octave.org/Summer_of_Code_Project_Ideas.




--

Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html

---------------------------------------------------------------------------

"I do not see why it should be of interest for the Octave community to write atranslator from Octave to Julia?" - for several reasons:

1) Julia is a much better language from the point of view of consistency and human understanding, so ultimately one should better switch to Julia and not lose the ability to use already developed Matlab/Octave code;

2) Julia is typically faster;
3) it looks like at the moment already there are more packages for Julia than for Octave;

4) Julia language runtime is distributed under MIT license - opposed to asphyxiating corporatocracy GPL (pretending to be a free license). I.e. end user can develop code in Julia and run it in closed source form at the place/device of final deployment.

SciLab has Matlab language frontend.

--Sergei.


Reply | Threaded
Open this post in threaded view
|

Re: Implementing advanced scientific calculator.

Mike Miller-4
On Fri, Mar 16, 2018 at 10:45:26 -0700, Sebastian Schöps wrote:
> By the way, I do
> not see why it should be of interest for the Octave community to write a
> translator from Octave to Julia?

On Fri, Mar 16, 2018 at 19:03:36 +0000, Sergei Steshenko wrote:
> 1) Julia is a much better language from the point of view of consistency
> and human understanding, so ultimately one should better switch to Julia
> and not lose the ability to use already developed Matlab/Octave code;

I think the implication is that Sergei believes the Octave community
should be spending its time and energy encouraging people to use tools
other than Octave.

--
mike



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Implementing advanced scientific calculator.

tmacchant
In reply to this post by Dildar Sk
-- mtmillerOn Fri, Mar 16, 2018 at 10:45:26 -0700, Sebastian Schöps wrote:

> > By the way, I do
> > not see why it should be of interest for the Octave community to write a
> > translator from Octave to Julia?
>
> On Fri, Mar 16, 2018 at 19:03:36 +0000, Sergei Steshenko wrote:
> > 1) Julia is a much better language from the point of view of consistency
> > and human understanding, so ultimately one should better switch to Julia
> > and not lose the ability to use already developed Matlab/Octave code;
>
> I think the implication is that Sergei believes the Octave community
> should be spending its time and energy encouraging people to use tools
> other than Octave.
>
> --
> mike
>
I myself am translating my octave code to Python + SciPy.  There seems be Matlab to Python translate tools.
Activity for them are mainly in Python side.
I think that, as Mike suggests, Octave community  need not pay on efforts to octave to Julia translator.

Tatsuro



Reply | Threaded
Open this post in threaded view
|

Re: Implementing advanced scientific calculator.

Sergei Steshenko
In reply to this post by Mike Miller-4



From: Mike Miller <[hidden email]>
To: [hidden email]
Sent: Friday, March 16, 2018 9:55 PM
Subject: Re: Implementing advanced scientific calculator.

On Fri, Mar 16, 2018 at 10:45:26 -0700, Sebastian Schöps wrote:
> By the way, I do
> not see why it should be of interest for the Octave community to write a
> translator from Octave to Julia?

On Fri, Mar 16, 2018 at 19:03:36 +0000, Sergei Steshenko wrote:

> 1) Julia is a much better language from the point of view of consistency
> and human understanding, so ultimately one should better switch to Julia
> and not lose the ability to use already developed Matlab/Octave code;


I think the implication is that Sergei believes the Octave community
should be spending its time and energy encouraging people to use tools
other than Octave.

--
mike
---------------------------------------------------------------------------------------

"I think the implication is that Sergei believes the Octave community should be spending its time and energy encouraging people to use tools other than Octave" - Sergei believes that the Octave community should first and foremost acknowledge the resounding failures and change its ways.

For example, several years ago I've created a heavily patched 'pkg.m' file and Jordy refused to accept it. I also proposed to architecture the packaging system - the community did not take the offer. Not only the packaging system was broken, but also 'mkoctfile'. I am not saying the latter didn't work, I'm saying it was conceptually broken, and this created problems in the packaging system.


First of all, reject the "Bazar" part of the "The Cathedral and the Bazaar" infamyOctave packaging system of several year ago is a direct consequence of the Bazaar part. And fixing packaging without fixing 'mkoctfile' is impossible


Second, acknowledge that SW evolves, and programming languages evolve. Look at number of packages at Julia Package Listing and compare it to the number of Octave packages.



The number is indicative of contributors' interest in the language.

Julia uses LLVM, and IMO LLVM is a reasonable approach.

Julia can directly call functions written in "C" and "Fortran": Calling C and Fortran Code · The Julia Language

.


And since many languages have "C" interface, this means those languages can be used with Julia too.

So, in essence I suggest the Octave community to stop reinventing the wheels and to use Julia as LLVM (the first 'L' stand for "low", but Julia is not at all low) for Octave.

And it's quite ironic that JWE, the founding father of Octave, now develops SciLab.

Again, IMO in modern world Matlab/Octave language should be just a front tend for something more generic. You probably also know that thanks to LLVM a lot of "C" code can be run in JavaScript - which, of course, makes it slower, but portable (and it can even be run in a web browser).

I do not know what (if any) money is involved in Octave development. If any money is involved, obviously the grants will be lower for just a front end than for the whole tool. Sergei is aware of It Is Difficult to Get a Man to Understand Something When His Salary Depends Upon His Not Understanding It | Quote Investigator .


, i.e. Sergei doesn't quite expect understanding of this Email from Octave developers. But hopefully young dudes and dudesses interested in Octave will understand it.


--Sergei.



Reply | Threaded
Open this post in threaded view
|

Re: Implementing advanced scientific calculator.

Dildar Sk
Sergei wrote,
"Another useful feature would be to write Octave to Julia (
https://julialang.org/ ) translator."

It would be my honour to take this as project and give a proposal over this.
But I think I will be not able to find any mentor.Going through this thread
I think you would best.
Can you help me in this.Thank you.



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html


Reply | Threaded
Open this post in threaded view
|

Re: Implementing advanced scientific calculator.

Sebastian Schöps
In reply to this post by Sergei Steshenko
Dear Sergei,

you are derailing the discussion and you are giving a student bad advice on
the matter which GSoC project to choose. Furthermore you are stating
questionable facts. I will take the effort to publicly disagree with you. If
you want to continue this debate, then please open a new thread.


Sergei Steshenko wrote
> For example, several years ago I've created a heavily patched 'pkg.m' file
> and Jordy refused to accept it. I also proposed to architecture the
> packaging system - the community did not take the offer. Not only the
> packaging system was broken, but also 'mkoctfile'. I am not saying the
> latter didn't work, I'm saying it was conceptually broken, and this
> created problems in the packaging system.

pkg.m is used by many people every day, so it's obviously not broken.
However, the Octave community knows very well that the package system is not
perfect. There is a GSoC project proposal dedicated to that topic.
Furthermore, there are ongoing discussions, e.g. recently at OctConf 2018,
see the wiki page. In conclusion: your information is outdated.


Sergei Steshenko wrote
> Second, acknowledge that SW evolves, and programming languages evolve.
> Look at number of packages at Julia Package Listing and compare it to the
> number of Octave packages. The number is indicative of contributors'
> interest in the language.

Just counting the number of packages and contributors is not a reasonable
measure, for example this disregards the effort and quality of each
contribution as well as its perspective stability, i.e., how long will Julia
and its packages be maintained? Obviously, finding a good measure how
languages evolve is difficult, but let's have a look to the most recent IEEE
ranking of the top programming Languages: Matlab/Octave is 14th and Julia on
31st position
(https://spectrum.ieee.org/static/interactive-the-top-programming-languages-2017).
Python is on 1st rank such that it would be a much more interesting
comparison. However, I guess most Octave developers do not care much about
these statistics and we all use other languages as well (in particular Julia
and Python which is evident if following this mailing list). In conclusion:
your argument is not well established and it's a straw man argument: nobody
dislikes Julia here and we are well aware that it features some interesting
ideas.
 

Sergei Steshenko wrote
> Julia uses LLVM, and IMO LLVM is a reasonable approach.
> Julia can directly call functions written in "C" and "Fortran": Calling C
> and Fortran Code · The Julia Language

Actually, Octave had embraced LLVM before Julia became popular, see
https://wiki.octave.org/JIT (<2012). Recently Julien was looking on this
mailing list for help to improve it.
 

Sergei Steshenko wrote
> And since many languages have "C" interface

Octave can be interfaced from C and Fortran and vice versa.


Sergei Steshenko wrote
> I do not know what (if any) money is involved in Octave development...

I will not comment on these unfriendly allegations but I ensure everybody
that this is not about money.

Coming back to the main point of this thread related to the funding
question: if GNU Octave gets GSoC funding then it's our duty to spend that
money on projects that improve Octave itself. Writing a translator to
another language is not in Octave's best interest and such a project has
almost no chance to be accepted. However, improving the LLVM backend would
be. However, this is a very difficult job and I am not sure if there is a
mentor available. If a student is interested, then you may contact Julien.

@Dildar Sk: I do not recommend to base you proposal on a Julia interface.

Regards,
Sebastian



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html


Reply | Threaded
Open this post in threaded view
|

Re: Implementing advanced scientific calculator.

Dildar Sk
Sebastian wrote
"@Dildar Sk: I do not recommend to base you proposal on a Julia interface. "

Then what about translating m-files to C++?
Or
what about the scientific calculator(GUI)?
What would be best?



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html


Reply | Threaded
Open this post in threaded view
|

Re: Implementing advanced scientific calculator.

Sebastian Schöps
Dildar Sk wrote
> Then what about translating m-files to C++?
> Or
> what about the scientific calculator(GUI)?
> What would be best?

Personally, I do not find those ideas convincing but eventually it's not my
decision to make. The first idea is crazily ambitious (did you think that
actually through? How would you do it?) and the second one is not improving
Octave itself which is our main interest (you propose to write a new
application with Octave as backend, right?).

The Octave community is open for new ideas but I suggest to study the
instructions and proposals at [1] before you propose something new. Let me
emphasise the following sentence "well thought out, adequately detailed,
realistic project plan".

Sorry, I do not want to recommend a particular project as this part of your
application.

Best,
Sebastian

[1] https://wiki.octave.org/Summer_of_Code_Project_Ideas.



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html


Reply | Threaded
Open this post in threaded view
|

Re: Implementing advanced scientific calculator.

jbect
In reply to this post by Sebastian Schöps
Le 18/03/2018 à 12:49, Sebastian Schöps a écrit :
> However, improving the LLVM backend would be. However, this is a very
> difficult job and I am not sure if there is a mentor available. If a
> student is interested, then you may contact Julien.

Sorry, but I am not able to mentor a student on this.  Lack of time and
skill...

My current knowledge of Octave's experimental LLVM-based JIT simply
allows me to say that :

* In its current form, it doesn't accomplish much.  Only very simple
loops can be compiled.

* As it is, LLVM 3.x with x <= 8 should be supported.  More work
(perhaps not very hard) is needed to make it work with more recent versions.

* Even for the very simple loops that were initially working when the
JIT was written by Max Brister, there are now some problems (exception
handling and complex numbers, at least).

@++
Julien