Good times, good times.
Well howdy, old-timer! That brings back some memories. (The '80s: after the dinosaurs, but before the giant armored sloths - back when neutrinos were massless and Λ was zero.) Did you work on Axiom? That was the finest…
You're welcome
Erin Ottmar's https://graspablemath.com is probably the best modern exploration of the idea.
At Apple? None whatsoever. It was a surprising fluke that even in the Apple of 1993. It only succeeded because so many people helped. That Apple was beleaguered at the time may have given employees a certain…
Btw, I wrote that, Ask Me Anything.
Amy O'Leary tells my favorite version of this story on This American Life: https://www.thisamericanlife.org/284/should-i-stay-or-should...
Yes, the numeric evaluation is vectorized via the Accelerate Framework's vForce and vDSP APIs. That is a significant performance improvement. The numeric evaluation remains a hotspot with vectorization, as that is where…
Applications / Utilities / Grapher is a different application (formerly Curvus Pro X from Arizona Software) which replaced the original Mac OS 7 Apple menu Graphing Calculator because I was very slow porting to Mac OS X.
That thread describes me working through performance issues in the initial port eight months ago. Those cases perform adequately now. Parsing is not a bottleneck. Walking the bytecode remains a performance hotspot, as…
Thank you! I can't believe that was thirty years ago. It feels unreal.
The math is internally represented as a tree for display and editing. Most of the performance critical code is the numeric evaluation when graphing. For that, the math is compiled to a linear byte code which vastly…
Most of the performance critical sections are numeric computation loops. I use the Unsafe APIs where profiling shows that the bounds-checking overhead is significant. In principle, I could get rid of reference counting…
I wrote the blog post. AMA.
It has been in continuous development since 1985. Before the port, parts were in C, C++, Objective-C, and Objective-C++, as well as Lex, Yacc, GLSL, and Python. Will do the top-level comment.
Yes, precisely. I looked into bridging to C++ initially, but it was impractical.
Still working on it. https://www.youtube.com/watch?v=m5h9KPkJ7eE
THANK YOU!!!
We were trying to build an iPad with 1992 technology. http://arno.org/arnotify/2010/01/penmac/
Thank you!
50, and still programming on the same codebase I started when I was 18.
Yes, as well as FullWrite and many other products.
http://www.pacifict.com/images/nyt.jpg
When the hardware failure is more frequent than failures in your software, we can consider that "good enough" (for consumer-level applications.)
I started programming on an HP-65 in the 70's. That was before graphing calculators, though.
Good times, good times.
Well howdy, old-timer! That brings back some memories. (The '80s: after the dinosaurs, but before the giant armored sloths - back when neutrinos were massless and Λ was zero.) Did you work on Axiom? That was the finest…
You're welcome
Erin Ottmar's https://graspablemath.com is probably the best modern exploration of the idea.
At Apple? None whatsoever. It was a surprising fluke that even in the Apple of 1993. It only succeeded because so many people helped. That Apple was beleaguered at the time may have given employees a certain…
Btw, I wrote that, Ask Me Anything.
Amy O'Leary tells my favorite version of this story on This American Life: https://www.thisamericanlife.org/284/should-i-stay-or-should...
Yes, the numeric evaluation is vectorized via the Accelerate Framework's vForce and vDSP APIs. That is a significant performance improvement. The numeric evaluation remains a hotspot with vectorization, as that is where…
Applications / Utilities / Grapher is a different application (formerly Curvus Pro X from Arizona Software) which replaced the original Mac OS 7 Apple menu Graphing Calculator because I was very slow porting to Mac OS X.
That thread describes me working through performance issues in the initial port eight months ago. Those cases perform adequately now. Parsing is not a bottleneck. Walking the bytecode remains a performance hotspot, as…
Thank you! I can't believe that was thirty years ago. It feels unreal.
The math is internally represented as a tree for display and editing. Most of the performance critical code is the numeric evaluation when graphing. For that, the math is compiled to a linear byte code which vastly…
Most of the performance critical sections are numeric computation loops. I use the Unsafe APIs where profiling shows that the bounds-checking overhead is significant. In principle, I could get rid of reference counting…
I wrote the blog post. AMA.
It has been in continuous development since 1985. Before the port, parts were in C, C++, Objective-C, and Objective-C++, as well as Lex, Yacc, GLSL, and Python. Will do the top-level comment.
Yes, precisely. I looked into bridging to C++ initially, but it was impractical.
Still working on it. https://www.youtube.com/watch?v=m5h9KPkJ7eE
THANK YOU!!!
We were trying to build an iPad with 1992 technology. http://arno.org/arnotify/2010/01/penmac/
Thank you!
50, and still programming on the same codebase I started when I was 18.
Yes, as well as FullWrite and many other products.
http://www.pacifict.com/images/nyt.jpg
When the hardware failure is more frequent than failures in your software, we can consider that "good enough" (for consumer-level applications.)
I started programming on an HP-65 in the 70's. That was before graphing calculators, though.