#3432 mathfuncs return strings? numbers?

obsolete: 8.5a5
Don Porter

dgp In Tcl 8.4, the only way to create a new math
function is via Tcl_CreateMathFunc

[13:17] dgp Using that interface, the return type of
the function had to be ont of the supported C types of
the Tcl_Value struct.

[13:18] dgp so mathfuncs were only good for computing
numerical things
[13:18] tclguy yes
[13:18] dgp With TIP 232 in place, that restriction is

[13:20] dgp % proc tcl::mathfunc::append {args} {
return [join $args ""]
% expr {append("foo","bar","soom")}

[13:21] dgp Is this new ability an intended
improvement? Or an unintended implementation consquence?
[13:21] dkf_ dgp: improvement
[13:22] dkf_ I don't know about "intended" though
[13:22] dgp don't judge too quickly...

[13:23] dkf_ What I can say is that I know how bad it
was before, having tried to write new functions using
that old API
[13:23] dgp % expr {append("N","a","N")}
domain error: argument not in valid range

[13:24] dgp if the [expr] core is supposed to check for
numeric-ness of the result of a function, then
screening out NaN's might make sense.
[13:24] dgp but if we intend string functions to work,
we need to stop doing that.
[13:25] dkf_ Earlier on, I said that NaN was "the
screaming horror hiding in the space between the 1s and
the 0s" and I meant it

[13:26] spjuth Try: expr {append("0","x","AF")}
[13:26] dgp same interp:
% expr {sqrt(-1)}
[13:26] dgp so either way, the HEAD is currently
[13:26] dkf_ it's the cvtToNumeric opcode that's wacky
[13:26] dgp but I'd like to know my opinions about
which way correctness lies aren't in gross conflict
with others.
[13:27] dgp % expr {append("0","x","AF")}
[13:30] dkf_ What would fail if line tclCompExpr.c:260
was commented out?
[13:30] dgp I'll test and find out...
[13:30] dkf_ since I think that's what is causing the
[13:32] dgp why is that line inactive in the sqrt()
[13:32] dkf_ probably a buggy INST_TRY_CVT_TO_NUMERIC

[13:34] dgp dkf, mucho failures regarding string rep of
[13:34] dgp [expr] apparently is supposed to produce
canonical string reps
[13:35] dgp % expr 0x1

spjuth Might be that sqrt(-1) contains a unary minus
operator, thus INST_TRY_ is skipped.


  • Kevin B KENNY

    Kevin B KENNY - 2006-07-30
    • assigned_to: kennykb --> dgp
  • Kevin B KENNY

    Kevin B KENNY - 2006-07-30

    Logged In: YES

    Ouch. I don't know, either. When I put the TIP together,
    I was thinking only of the new numeric types (chiefly
    bigints) and not of strings.

    It's obvious that we should try to convert a string to
    numeric if we pass it into something (such as an arithmetic
    operator) that requires a number.

    It's also a historical fact that people use [expr {$x}]
    to make $x into a canonical number - it is expected that
    [expr 0xff] will return 255.

    So it appears, for well or ill, that [expr] is for numbers,
    and not for strings, as attractive as the latter seems.
    Perhaps we should TRY_CVT_TO_NUMERIC on the result of
    math functions?

  • Don Porter

    Don Porter - 2006-08-31

    Logged In: YES

    This is now a Dup of 1541274

  • Don Porter

    Don Porter - 2006-08-31
    • status: open --> closed-duplicate