avitzur

6 ms·

1.
by avitzur 3mo ago
Good times, good times.
2.
by avitzur 3y ago
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 crafted computer
3.
by avitzur 3y ago
You're welcome
4.
by avitzur 4y ago
Erin Ottmar's https://graspablemath.com is probably the best modern exploration of the idea.
5.
by avitzur 4y ago
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 devil-may-care attitude towards
6.
by avitzur 4y ago
Btw, I wrote that, Ask Me Anything.
7.
by avitzur 4y ago
Amy O'Leary tells my favorite version of this story on This American Life: https://www.thisamericanlife.org/284/should-i-stay-or-should...
8.
by avitzur 4y ago
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 the app does mo
9.
by avitzur 4y ago
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.
10.
by avitzur 4y ago
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 that is where all the
11.
by avitzur 4y ago
Thank you! I can't believe that was thirty years ago. It feels unreal.
12.
by avitzur 4y ago
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 improves locality of refe
13.
by avitzur 4y ago
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 overhead by using val
14.
by avitzur 4y ago
I wrote the blog post. AMA.
15.
by avitzur 4y ago
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.
16.
by avitzur 4y ago
Yes, precisely. I looked into bridging to C++ initially, but it was impractical.
17.
by avitzur 6y ago
Still working on it. https://www.youtube.com/watch?v=m5h9KPkJ7eE
18.
by avitzur 8y ago
THANK YOU!!!
19.
by avitzur 8y ago
We were trying to build an iPad with 1992 technology. http://arno.org/arnotify/2010/01/penmac/
20.
by avitzur 8y ago
Thank you!
21.
by avitzur 9y ago
50, and still programming on the same codebase I started when I was 18.
22.
by avitzur 12y ago
Yes, as well as FullWrite and many other products.
23.
by avitzur 12y ago
http://www.pacifict.com/images/nyt.jpg
24.
by avitzur 19y ago
When the hardware failure is more frequent than failures in your software, we can consider that "good enough" (for consumer-level applications.)
25.
by avitzur 20y ago
I started programming on an HP-65 in the 70's. That was before graphing calculators, though.