On 2022-12-11 19:25, James Harris wrote:
On 11/12/2022 17:21, Dmitry A. Kazakov wrote:
On 2022-12-11 18:00, James Harris wrote:
On 07/12/2022 19:37, Dmitry A. Kazakov wrote:
But where did you read that the specific term 'subtype' should
thereafter be applied to implicit conversions?
Conversion is an implementation of substitution.
Conversion is a conversion, not a substitution!
It did not say it is. I said it an implementation of.
How would you substitute int for float without a conversion?
I don't have implicit conversions of declared types. They must be
written explicitly. Undeclared types (big int, big uint, big float,
character, string, boolean etc) would have automatic conversions. Not
sure if that affects your assessment.
Call implicit automatic, automatic implicit. It does not change the semantics and the intent. The intent and the meaning is to substitute
one type for another transparently to the syntax.
On 12/12/2022 11:26, Bart wrote:
And as David said, cube roots aren't that common. It might have a
button for it on my Casio, that might be because it's oriented towards
solving school maths problems.
I think rather than having a cube root function, perhaps an nth root function would make some sense. Then you could write "root(x, 3)" -
that's about as neat and potentially as accurate as any other solution.
On 11/12/2022 18:01, James Harris wrote:
On 07/12/2022 16:53, Dmitry A. Kazakov wrote:
On 2022-12-07 17:42, James Harris wrote:
On 06/12/2022 00:25, Bart wrote:
If cube roots were that common, would you write that asIn language terms I think I'd go for x ** (1.0 / 3.0). If a
x**0.33333333333 or x**(1.0/3.0)? There you would welcome cuberoot(x)! >>>>
programmer wanted to put it in a function there would be nothing
stopping him.
I think the point Bart was making was that 1/3 had no exact
representation in binary floating-point numbers. If cube root used a
special algorithm, you would have a trouble to decide when to switch
to it.
If you and Bart mean that a cuberoot function would have to decide on
a rounding direction for 1.0/3.0 then I agree; it's a good point.
Actually, I was concerned with aesthetics.
The precision of 1.0/3 is something I hadn't considered, but DAK's point
is, if a compiler knew of a fast cube root algorithm and wanted to special-case A**B when B was 1.0/3, then how close to 'one third' would
B have to be before it could assume that a cube-root was in fact what
was intended? Given that there is no precise representation of 'one
third' anyway.
Far easier to just a provide something like 'cuberoot()' then it will
know, and so will people reading the code.
I haven't worked through the many issues surrounding floats, yet, but
they would probably have similar to integers, i.e. delimited areas of
code could have a default rounding mode. One could write something
along the lines of
with float-rounding-mode = round-to-positive-infinity
return x ** (1.0 / 3.0)
with end
In such code the division would be rounded up to something like
0.3333334.
To incorporate that much control in a function would require many
functions such as
cuberoot_round_up
cuberoot_round_down
cuberoot_round_towards_zero
Huh? Who cares about the rounding of cube root?! As I said it was merely about detecting whether this was a cube root.
and other similar horrors. Those names are, in fact, misleading as
they seem to apply to the cube root rather than the division within it
- which makes the idea of a function even worse.
Oh, you are talking abut that! Maybe you need a function like isthisreallyathirdorjustsomethingclose() instead.
You'll be glad to know I won't support any of that nonsense (such as
allowing a redefinition of what 2 means) but what do you mean about
the program text? Say the text has
two: const = 2
f(2)
f(two)
I don't see any semantic difference between 2 and two. Nor does
either form imply either storage or the lack of storage.
That being the case, do you still see a semantic difference between 2
and two?
On 12/12/2022 10:26, Bart wrote:
What do you make of David's suggestion to have a "root" function which I would probably have as
root(2, x) -> square root of x
root(3, x) -> cube root of x
On 11/12/2022 19:08, Dmitry A. Kazakov wrote:
On 2022-12-11 19:25, James Harris wrote:
On 11/12/2022 17:21, Dmitry A. Kazakov wrote:
On 2022-12-11 18:00, James Harris wrote:
On 07/12/2022 19:37, Dmitry A. Kazakov wrote:
But where did you read that the specific term 'subtype' should
thereafter be applied to implicit conversions?
Conversion is an implementation of substitution.
Conversion is a conversion, not a substitution!
It did not say it is. I said it an implementation of.
How would you substitute int for float without a conversion?
I don't have implicit conversions of declared types. They must be
written explicitly. Undeclared types (big int, big uint, big float,
character, string, boolean etc) would have automatic conversions. Not
sure if that affects your assessment.
Call implicit automatic, automatic implicit. It does not change the
semantics and the intent. The intent and the meaning is to substitute
one type for another transparently to the syntax.
Fine but that still doesn't imply a 'sub' type - for any reasonable
meaning of the term.
I accept that you have a different interpretation of 'subtype' and
that's fine but it seems a confusing use of language. Maybe there's a
better term that everyone would be happy with but I think of a subtype
as being diminutive compared to another, such as integers which have a smaller range.
thou: integer range 0..999
hund: s range 0..99
where hund could be understood to be a subtype of thou. But not the
other way round!
On 11/12/2022 19:21, Dmitry A. Kazakov wrote:
On 2022-12-11 19:45, James Harris wrote:
On 11/12/2022 17:43, Dmitry A. Kazakov wrote:
On 2022-12-11 18:18, James Harris wrote:
On 07/12/2022 19:39, Dmitry A. Kazakov wrote:
On 2022-12-07 19:09, James Harris wrote:
On 06/12/2022 08:09, Dmitry A. Kazakov wrote:
On 2022-12-06 00:04, James Harris wrote:
On 05/12/2022 07:50, Dmitry A. Kazakov wrote:
...
No. Types are not the only control in a programming language. An >>>>>>> /object/ has a type.At least you've now added operations so you are getting there. ;-) >>>>>>>>Good. Now you see why in T and in out T cannot be the same type? >>>>>>>
If you want to use the term for something else you are free to do >>>>>> so. But if you accept the standard definition you must also accept >>>>>> all consequences of.
Potentially fair but where did you read a definition of 'type'
which backs up your point?
It is a commonly accepted definition AFAIK coming from mathematical
type theories of the beginning of the last century.
Wikipedia (ADT = abstract datatype):
"Formally, an ADT may be defined as a "class of objects whose
logical behavior is defined by a set of values and a set of
operations"; this is analogous to an algebraic structure in
mathematics."
That rather backs up my assertion that types are of /objects/ rather
than of /uses/. IOW a piece of code could treat an object as
read-only but that doesn't change the type of the object.
No idea what this is supposed to mean. You asked where it comes from,
I gave you the quote.
You referred to an ADT rather than a type.
From the same source:
"A data type constrains the possible values that an expression, such as
a variable or a function, might take. This data type defines the
operations that can be done on the data, the meaning of the data, and
the way values of that type can be stored."
https://en.wikipedia.org/wiki/Data_type
Note, the operations which "can be done on the data", not "can be done
by a certain function".
Again, you do not accept common definition, give your own and explain
how stupid the rest of the world is by not using it.
Ahem, I'm happy with the aforementioned definition. It's you who is
seeking an alteration.
So what? Again any particular weakness of your type system by no means
change the point. Which, let me repeat is, you can always resolve
ambiguities by qualifying types.
There's no weakness in that type system. On the contrary, it requires
and would enforce precision and explicitness from the programmer.
Such inconsistency is something that should be resisted.
What inconsistency?
See the example, above, on references. It would be inconsistent to
automatically dereference when the rest of the language requires
explicit type matching.
I do not see any inconsistency. See the definition of:
Wikipedia:
"In classical deductive logic, a consistent theory is one that does
not lead to a logical contradiction."
I mean 'inconsistency' such as requiring explicit conversions in one
place but not in another.
On 11/12/2022 19:32, Dmitry A. Kazakov wrote:
On 2022-12-11 19:01, James Harris wrote:
On 07/12/2022 16:53, Dmitry A. Kazakov wrote:
On 2022-12-07 17:42, James Harris wrote:
On 06/12/2022 00:25, Bart wrote:
If cube roots were that common, would you write that as
x**0.33333333333 or x**(1.0/3.0)? There you would welcome
cuberoot(x)!
In language terms I think I'd go for x ** (1.0 / 3.0). If a
programmer wanted to put it in a function there would be nothing
stopping him.
I think the point Bart was making was that 1/3 had no exact
representation in binary floating-point numbers. If cube root used a
special algorithm, you would have a trouble to decide when to switch
to it.
If you and Bart mean that a cuberoot function would have to decide on
a rounding direction for 1.0/3.0 then I agree; it's a good point. I
haven't worked through the many issues surrounding floats, yet, but
they would probably have similar to integers, i.e. delimited areas of
code could have a default rounding mode. One could write something
along the lines of
with float-rounding-mode = round-to-positive-infinity
return x ** (1.0 / 3.0)
with end
You cannot do that with available hardware in a reasonable way.
Hardware rounding is set.
Not so. Rounding towards infinities is provided in hardware.
A certain language (Ada?) might have you believe there is only one
rounding mode in hardware but that's not so.
IEEE 754 defines five
according to
https://en.wikipedia.org/wiki/IEEE_754#Rounding_rules
I currently define 12 rounding modes for integers and I guess that
similar may apply for floats but I've not explored that yet. Either way,
if a programmer wanted a mode which the IEEE did not define for hardware
it would be the compiler's job to emit equivalent instructions.
In such code the division would be rounded up to something like
0.3333334.
To incorporate that much control in a function would require many
functions such as
cuberoot_round_up
cuberoot_round_down
cuberoot_round_towards_zero
and other similar horrors.
It is no horrors, it is interval computations. Interval-valued
function F returns an interval containing the mathematically correct
result. Hardware implementations are interval-valued with the interval
width of two adjacent machine numbers. Then rounding chooses one of
the bounds.
OT but I'd like to see a float implementation which instead of a single value always calculated upper and lower bounds for fp results.
On 12/12/2022 15:18, David Brown wrote:
On 12/12/2022 11:26, Bart wrote:
And as David said, cube roots aren't that common. It might have a
button for it on my Casio, that might be because it's oriented
towards solving school maths problems.
I think rather than having a cube root function, perhaps an nth root
function would make some sense. Then you could write "root(x, 3)" -
that's about as neat and potentially as accurate as any other solution.
I like that! I'd have to work through issues including integers vs
floats but it would appear to be simple, clear, and general. I may do something similar, perhaps with the root first to permit results to be tuples.
root(3, ....) ;cube root
so that
root(3, 8) -> 2
root(3, 8, 1000) -> (2, 10)
On 12/12/2022 22:41, James Harris wrote:
On 12/12/2022 10:26, Bart wrote:
What do you make of David's suggestion to have a "root" function which
I would probably have as
root(2, x) -> square root of x
root(3, x) -> cube root of x
It's OK. It solves the problem of special-casing cube-roots, and others
of interest.
Probably I wouldn't have it as built-in, as I have no great interest in
cube roots (other than allowing ∛(x) would be cool). Maybe as an
ordinary macro or function that implements it on top of **, but is a
clearer alternative. nthroot() is a another possibility (as is an infix version `3 root x`, with precedence the same as **).
But I would continue to use sqrt since I first saw that in a language in '75, and I see no reason to drop it.
On 12/12/2022 23:30, James Harris wrote:
I like that! I'd have to work through issues including integers vs
floats but it would appear to be simple, clear, and general. I may do
something similar, perhaps with the root first to permit results to be
tuples.
root(3, ....) ;cube root
so that
root(3, 8) -> 2
root(3, 8, 1000) -> (2, 10)
This last one is :
root(n, a, b) -> (a ^ 1/n, b ^ 1/n)
?
Is that a general feature you have - allowing functions to take extra arguments and returning tuples? If so, what is the point? (I don't
mean I think it is pointless, I mean I'd like to know what you think is
the use-case!)
Just to annoy Bart :-), you could do this by implementing currying in
your language along with syntactic sugar for the common functional programming "map" function (which applies a function to every element in
a list).
Given a function "foo(a, b)" taking two inputs, "currying" would let the user treat "foo(a)" as a function that takes one input "b" and returns "foo(a, b)". Thus "foo(a, b)" and "foo(a)(b)" do the same thing. (In Haskell, you don't need the parentheses around parameters, and
associativity means that "foo a b" is he same thing as "(foo a) b" - all
use of multiple parameters is by currying.)
Now allow the syntax "foo [a, b, c]" to mean "map foo [a, b, c]" and
thus "[foo(a), foo(b), foo(c)]" - i.e., application of a single-input function to a list/tuple should return a list/tuple of that function
applied to each element.
The user (or library) can then define the single function "root(n, x)",
and the user can write "root(3)[8, 1000]" to get "[2, 10]" without any special consideration in the definition of "root".
Now allow the syntax "foo [a, b, c]" to mean "map foo [a, b, c]" and
thus "[foo(a), foo(b), foo(c)]" - i.e., application of a single-input function to a list/tuple should return a list/tuple of that function
applied to each element.
On 13/12/2022 01:27, Bart wrote:
On 12/12/2022 22:41, James Harris wrote:
On 12/12/2022 10:26, Bart wrote:
What do you make of David's suggestion to have a "root" function
which I would probably have as
root(2, x) -> square root of x
root(3, x) -> cube root of x
It's OK. It solves the problem of special-casing cube-roots, and
others of interest.
Probably I wouldn't have it as built-in, as I have no great interest
in cube roots (other than allowing ∛(x) would be cool). Maybe as an
ordinary macro or function that implements it on top of **, but is a
clearer alternative. nthroot() is a another possibility (as is an
infix version `3 root x`, with precedence the same as **).
But I would continue to use sqrt since I first saw that in a language
in '75, and I see no reason to drop it.
Square roots are very common, so it makes sense to have an individual function for them. At the very least, the implementation of "root"
should have a special case for handling roots 0, 1 and 2.
(As always, I would never have something as a built-in function or
keyword if it could equally well be made in a library. And if you can't make library functions as efficient as builtins, find a better way to
handle your standard library - standard libraries don't need to follow platform ABI's.)
On 2022-12-13 15:10, David Brown wrote:
Square roots are very common, so it makes sense to have an individual
function for them. At the very least, the implementation of "root"
should have a special case for handling roots 0, 1 and 2.
(As always, I would never have something as a built-in function or
keyword if it could equally well be made in a library. And if you
can't make library functions as efficient as builtins, find a better
way to handle your standard library - standard libraries don't need to
follow platform ABI's.)
If x**y denotes power, then x//y should do the opposite. So x//2 is
square root. I cannot help the proponents of x^y notation... (:-))
On 2022-12-13 15:10, David Brown wrote:
On 13/12/2022 01:27, Bart wrote:
On 12/12/2022 22:41, James Harris wrote:
On 12/12/2022 10:26, Bart wrote:
What do you make of David's suggestion to have a "root" function
which I would probably have as
root(2, x) -> square root of x
root(3, x) -> cube root of x
It's OK. It solves the problem of special-casing cube-roots, and
others of interest.
Probably I wouldn't have it as built-in, as I have no great interest
in cube roots (other than allowing ∛(x) would be cool). Maybe as an
ordinary macro or function that implements it on top of **, but is a
clearer alternative. nthroot() is a another possibility (as is an
infix version `3 root x`, with precedence the same as **).
But I would continue to use sqrt since I first saw that in a language
in '75, and I see no reason to drop it.
Square roots are very common, so it makes sense to have an individual
function for them. At the very least, the implementation of "root"
should have a special case for handling roots 0, 1 and 2.
(As always, I would never have something as a built-in function or
keyword if it could equally well be made in a library. And if you
can't make library functions as efficient as builtins, find a better
way to handle your standard library - standard libraries don't need to
follow platform ABI's.)
If x**y denotes power, then x//y should do the opposite. So x//2 is
square root. I cannot help the proponents of x^y notation... (:-))
On 13/12/2022 15:13, Dmitry A. Kazakov wrote:
On 2022-12-13 15:10, David Brown wrote:
Square roots are very common, so it makes sense to have an individual
function for them. At the very least, the implementation of "root"
should have a special case for handling roots 0, 1 and 2.
(As always, I would never have something as a built-in function or
keyword if it could equally well be made in a library. And if you
can't make library functions as efficient as builtins, find a better
way to handle your standard library - standard libraries don't need
to follow platform ABI's.)
If x**y denotes power, then x//y should do the opposite. So x//2 is
square root. I cannot help the proponents of x^y notation... (:-))
I had thought the same thing. But "//" is more useful for other things (aside from comments), eg Python uses it for integer divide; I'd
reserved it to construct rational numbers.
But then thinking about it some more:
x**3 means x*x*x
x//3 doesn't means x/x/x
On 13/12/2022 16:13, Dmitry A. Kazakov wrote:
On 2022-12-13 15:10, David Brown wrote:
On 13/12/2022 01:27, Bart wrote:
On 12/12/2022 22:41, James Harris wrote:
On 12/12/2022 10:26, Bart wrote:
What do you make of David's suggestion to have a "root" function
which I would probably have as
root(2, x) -> square root of x
root(3, x) -> cube root of x
It's OK. It solves the problem of special-casing cube-roots, and
others of interest.
Probably I wouldn't have it as built-in, as I have no great interest
in cube roots (other than allowing ∛(x) would be cool). Maybe as an >>>> ordinary macro or function that implements it on top of **, but is a
clearer alternative. nthroot() is a another possibility (as is an
infix version `3 root x`, with precedence the same as **).
But I would continue to use sqrt since I first saw that in a
language in '75, and I see no reason to drop it.
Square roots are very common, so it makes sense to have an individual
function for them. At the very least, the implementation of "root"
should have a special case for handling roots 0, 1 and 2.
(As always, I would never have something as a built-in function or
keyword if it could equally well be made in a library. And if you
can't make library functions as efficient as builtins, find a better
way to handle your standard library - standard libraries don't need
to follow platform ABI's.)
If x**y denotes power, then x//y should do the opposite. So x//2 is
square root. I cannot help the proponents of x^y notation... (:-))
x ⌄ y, perhaps? :-)
On 2022-12-13 16:32, David Brown wrote:
On 13/12/2022 16:13, Dmitry A. Kazakov wrote:
On 2022-12-13 15:10, David Brown wrote:
On 13/12/2022 01:27, Bart wrote:
On 12/12/2022 22:41, James Harris wrote:
On 12/12/2022 10:26, Bart wrote:
What do you make of David's suggestion to have a "root" function
which I would probably have as
root(2, x) -> square root of x
root(3, x) -> cube root of x
It's OK. It solves the problem of special-casing cube-roots, and
others of interest.
Probably I wouldn't have it as built-in, as I have no great
interest in cube roots (other than allowing ∛(x) would be cool).
Maybe as an ordinary macro or function that implements it on top of >>>>> **, but is a clearer alternative. nthroot() is a another
possibility (as is an infix version `3 root x`, with precedence the >>>>> same as **).
But I would continue to use sqrt since I first saw that in a
language in '75, and I see no reason to drop it.
Square roots are very common, so it makes sense to have an
individual function for them. At the very least, the implementation >>>> of "root" should have a special case for handling roots 0, 1 and 2.
(As always, I would never have something as a built-in function or
keyword if it could equally well be made in a library. And if you
can't make library functions as efficient as builtins, find a better
way to handle your standard library - standard libraries don't need
to follow platform ABI's.)
If x**y denotes power, then x//y should do the opposite. So x//2 is
square root. I cannot help the proponents of x^y notation... (:-))
x ⌄ y, perhaps? :-)
I dismissed it because it looks as x or/union y... (:-))
On 13/12/2022 16:38, Dmitry A. Kazakov wrote:
On 2022-12-13 16:32, David Brown wrote:
On 13/12/2022 16:13, Dmitry A. Kazakov wrote:
On 2022-12-13 15:10, David Brown wrote:
On 13/12/2022 01:27, Bart wrote:
On 12/12/2022 22:41, James Harris wrote:
On 12/12/2022 10:26, Bart wrote:
What do you make of David's suggestion to have a "root" function >>>>>>> which I would probably have as
root(2, x) -> square root of x
root(3, x) -> cube root of x
It's OK. It solves the problem of special-casing cube-roots, and
others of interest.
Probably I wouldn't have it as built-in, as I have no great
interest in cube roots (other than allowing ∛(x) would be cool). >>>>>> Maybe as an ordinary macro or function that implements it on top
of **, but is a clearer alternative. nthroot() is a another
possibility (as is an infix version `3 root x`, with precedence
the same as **).
But I would continue to use sqrt since I first saw that in a
language in '75, and I see no reason to drop it.
Square roots are very common, so it makes sense to have an
individual function for them. At the very least, the
implementation of "root" should have a special case for handling
roots 0, 1 and 2.
(As always, I would never have something as a built-in function or
keyword if it could equally well be made in a library. And if you >>>>> can't make library functions as efficient as builtins, find a
better way to handle your standard library - standard libraries
don't need to follow platform ABI's.)
If x**y denotes power, then x//y should do the opposite. So x//2 is
square root. I cannot help the proponents of x^y notation... (:-))
x ⌄ y, perhaps? :-)
I dismissed it because it looks as x or/union y... (:-))
To some (C programmers), "x ^ y" looks like "x xor y", while to others (logicians) it looks like "x and y". We have too few symbols,
especially if we restrict ourselves to ones easily typed on many keyboards!
And what operator shall we use for tetration? "x ^^ y" ? "x *** y" ?
Cube roots are arguably used often enough to be worth implementing >> separately from "** (1/3)" or near equivalent.Really? In what context? Square roots occur all over the place, but
I can't think of a single realistic use of cube roots that are not
general nth roots (such as calculating geometric means). [...]
Then the error from "1/3"You would almost certainly not use Chebychev's or other polynomials
is irrelevant. But if this matters to you, you would need to use serious >> numerical analysis and computation beyond the normal scope of this group,
such as interval arithmetic and Chebychev polynomials.
for calculating cube roots, unless you were making something like a specialised pipelined implementation in an ASIC or FPGA.
Newton-Raphson iteration, or related algorithms, are simpler and
converge quickly without all the messiness of ranges.
On 12/12/2022 09:11, David Brown wrote:
[I wrote:]
Cube roots are arguably used often enough to be worth implementingReally? In what context? Square roots occur all over the place, but
separately from "** (1/3)" or near equivalent.
I can't think of a single realistic use of cube roots that are not
general nth roots (such as calculating geometric means). [...]
Well, the most obvious one is finding the edge of a cube of given volume! Yes, I've done that occasionally.
I found a couple of occurrences
of "cbrt" in my solutions to some [~200] of the Euler problems [I tackle
only ones that seem interesting], in both cases to find upper bounds on how far a calculation of n^3 needs to go for some condition to hold.
Another
use was when our prof of number theory came to me with some twisted cubics [qv] and asked me to find some solutions to associated cubic equations [sadly, it was ~15 years ago and I've forgotten the details]. My most recent personal use seems to have been in constructing a colour map for a Mandelbrot program, so aesthetic rather than important. IOW, I wouldn't claim major usage, but not negligible either.
Then the error from "1/3"You would almost certainly not use Chebychev's or other polynomials
is irrelevant. But if this matters to you, you would need to use
serious
numerical analysis and computation beyond the normal scope of this
group,
such as interval arithmetic and Chebychev polynomials.
for calculating cube roots, unless you were making something like a
specialised pipelined implementation in an ASIC or FPGA.
Chebychev polynomials have the advantage of minimising the error over a range, so typically converge significantly faster than other ways
of calculating library functions /as long as/ you can pre-compute the
number of terms needed and thus the actual conversion back into a normal polynomial.
This typically saves an iteration or two /and/ having a
loop [as you can unroll it] /and/ testing whether to go round again,
compared with an iterative method. I had a colleague who was very keen
on Pade approximations, but I didn't find them any faster; admittedly,
that was in the '60s and '70s when I was heavily involved in numerical
work for astrophysics [and hitting limits on f-p numbers, store sizes,
time allocations, ...]; I don't know what the current state of the art
is on modern hardware.
Newton-Raphson iteration, or related algorithms, are simpler and
converge quickly without all the messiness of ranges.
Simpler for casual use, certainly, esp if you have no inside knowledge of the hardware. But you still need to do range reduction,
as N-R is only linear if you start a long way from the root. [Atlas
had a nifty facility whereby the f-p exponent was a register, so you
could get reasonably close to an n-th root simply by dividing that
register by n.]
[But my real point here, as in my previous article, is not to promote any particular numerical technique, but to point out that the calculation of library functions in the Real World is not an amateur activity, and needs serious NA, well beyond what most undergraduates encounter, and well beyond the normal scope of this group.]
On 12/12/2022 23:30, James Harris wrote:
On 12/12/2022 15:18, David Brown wrote:
On 12/12/2022 11:26, Bart wrote:
And as David said, cube roots aren't that common. It might have a
button for it on my Casio, that might be because it's oriented
towards solving school maths problems.
I think rather than having a cube root function, perhaps an nth root
function would make some sense. Then you could write "root(x, 3)" -
that's about as neat and potentially as accurate as any other solution.
I like that! I'd have to work through issues including integers vs
floats but it would appear to be simple, clear, and general. I may do
something similar, perhaps with the root first to permit results to be
tuples.
root(3, ....) ;cube root
so that
root(3, 8) -> 2
root(3, 8, 1000) -> (2, 10)
This last one is :
root(n, a, b) -> (a ^ 1/n, b ^ 1/n)
?
Is that a general feature you have - allowing functions to take extra arguments and returning tuples? If so, what is the point? (I don't
mean I think it is pointless, I mean I'd like to know what you think is
the use-case!)
I think James' language is not that high level so functional would not
be a good fit, but he says this is making use of 'tuples'.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 919 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 46:33:42 |
| Calls: | 12,183 |
| Calls today: | 3 |
| Files: | 186,524 |
| Messages: | 2,236,085 |