In processing (processing.org programming language) many people
implement fast sin/cos math using lookup tables, with either limited
precision but accurate degree input. Or with limited precision (say 0.25
degree) and limited accuracy, with radian input (and typically table is
stored as array of floats). Is there any point in trying to wrap a java
version into jruby (not for everyone, but just local to say
ruby-processing) for graphical work.
On a related note I have written a 2D and 3D vector library
https://github.com/jashkenas/ruby-processing/blob/master/library/vecmath/lib/vec.rb
in purely ruby for use with ruby-processing, would I gain anything by
re-implementing it in java and writing a jruby wrapper, like yokolets
Fraction, that wraps Apache Commons Math API to provide a ruby version.
yokolet's notelets: Extending JRuby.
OK no-one replied, I did more research and decided to put my foot in the
water. Here is progress so far at implementing my 2D ruby vector library
in JRuby (java)
Ruby Processing: Experiments with JRuby Integration (for ruby-processing).
I did this because it looks to me that the biggest slowdown is calling
java from ruby and vice-versa. I have yet to test performance, but it
was an interesting exercise.
Hi Martin,
Why don’t you use MDMatrix class from MDArray?
I haven’t replied before because I don’t really understand why you need
to
do all those complex calls and don’t just import java methods to jruby.
Cheers,
Rodrigo
Em 26/04/2014 13:18, “Martin P.” [email protected] escreveu:
I have now made my experimental JRuby extension available at github
https://github.com/ruby-processing/RVecMath
I’m hesitant to offer it as possible template because it is my first
attempt, and there is an absolute dearth of examples (apart from
yokolets excellent example without which I would have never started).
However judging my spec test it at least all seems to work. I have
expanded yokolets example to include a static method (other than new)
methods which take a variable number of arguments etc. Many of these
additional features were partly achieved by trial and error. If I was
confident I was right I would write a guide.
I have now added to the functionality of my Vecmath library
https://github.com/ruby-processing/RVecMath which will very likely get
incorporated into ruby-processing. Perhaps the most useful feature is
that of the ArcBall functionality, which can be implemented on the ruby
side with a one liner (by making use of java reflection in processing).
Less interesting is the degree input and degree precision sine / cosine
lookup tables that manage at best 30-40% performance gain over regular
Math.sin and Math.cos. In practice this (ie in a ruby-processing sketch)
performance gain may be even more marginal.
I was only going on this
https://twitter.com/headius/status/349225854842306560 from Charlie. In
my experiments it is almost pointless trying to do speed ups in java as
these will not come through to ruby-processing performance. The point of
ruby-processing is to be able to write regular ruby code. If you only
wanted performance you would stick to vanilla processing. Performance is
not bad, even with my Vecmath libary written in ruby, I reasoned that if
it were pre-compiled it might work even better. From the users point of
view my library will appear as though it were written in ruby.