Topic: getstring with getpoint?

[irneb]

I would still like to see the benchmark comparison for BricsCad though. IMO that might be a lot faster.

And for those thinking this is just for input. Consider reading from a CSV file several 1000 points, you want as little to hangup the system as possible.

An interesting lesson to be learned: if you have subroutines for your subroutines, within a program, do not define them within the subroutine, but rather define them within the main program.

To a point. The issue is that you then end up either having to pass all variables as arguments, in which case you'd be losing some efficiency (passing arguments has an extra overhead over just using global variables). Or you need to ensure no variable name clashes due to the dynamic scoping. Performance-wise it makes sense yes, but it could cause bugs if you're not careful.

[alanjt]

I would still like to see the benchmark comparison for BricsCad though. IMO that might be a lot faster.

And for those thinking this is just for input. Consider reading from a CSV file several 1000 points, you want as little to hangup the system as possible.

An interesting lesson to be learned: if you have subroutines for your subroutines, within a program, do not define them within the subroutine, but rather define them within the main program.

To a point. The issue is that you then end up either having to pass all variables as arguments, in which case you'd be losing some efficiency (passing arguments has an extra overhead over just using global variables). Or you need to ensure no variable name clashes due to the dynamic scoping. Performance-wise it makes sense yes, but it could cause bugs if you're not careful.

Fair point. I didn't really mean using subroutines that called out to variables that are defined elsewhere.
eg.
(defun foo (x) (rtos x var1 var2))

[CAB]

Hum, a bit surprised by that.

[roy_043]

I would still like to see the benchmark comparison for BricsCad though. IMO that might be a lot faster.

Further analysis shows that the mode argument is disregarded by BricsCAD's (distof) implementation. Comparing the txt2num_* functions therefore does not make a lot of sense.
But BricsCAD's (distof) is fast (even on a, not so fast, 7-year old laptop):

Code: [Select]

(setq str "25648645413219876846521684.584974654987")
(KGX_BenchMark '((distof str)) 65536)

; Benchmarking .......... elapsed milliseconds / relative timing <65536 iterations>

;   (DISTOF STR) ..... 171 / 1.00 <fastest> <slowest>