Is there a particular purpose of writing the functions in Rhai script?

Otherwise, this package would really be a very useful one for many people...

But having to run scripts for every function will probably make it too slow for most applications?

It may not be a good idea to pull in features for rhai, since cargo will merge these features to the user's.

metadata and serde are harmless, but will bloat the user's build. unchecked, however, will turn off the user's error checking, which may not be what he wants.

I am not sure if there is any solid dependency on any rhai feature. It seems that unchecked is not really needed, but metadata and serde are needed only to run doc-tests.

Nevertheless, if you move the functions into Rust, I suppose most of the dependencies will go away since the custom build step won't be necessary.

@cmccomb looking good! Especially making lots of dependencies option.

I'd suggest adding a feature to gate rustyline, since it may not be always necessary unless the user is writing a REPL.

Also, maybe a feature to gate rand -- but since this is a scientific computing package, maybe random numbers should be standard...

Originally posted by @schungx in https://github.com/rhaiscript/rhai-sci/issues/9#issuecomment-1207113418

Right now, unfortunately due to the need to build documentation in lib.rs, the build script requires metadata on the rhai crate.

This means that all users of the library will be forced to include metadata in all their builds, greatly bloating binary size.

I suggest making a new feature flag, which pulls in rhai/metadata for full docs; the default without this flag simply skips the documentation building step in build.rs.

We can put this inside Cargo.toml to make sure that crate docs have the documentation:

[package.metadata.docs.rs]
features = ["metadata" ]

In some of the array functions, I see code that checks the first element and then assumes the rest of the array to be of the same type (usually by checking whether we're working with an INT or FLOAT array):

if arr[0].is::<INT>() {
    :
} else if arr[0].is::<FLOAT>() {
    :
} ...

This is perhaps necessary for statically-typed languages, but Rhai is dynamic so this restriction is rarely necessary as the users may expect to be able to freely mix INT with FLOAT.

For example, we can consider to do this instead: Assume the array is an INT if and only if all elements are INT. Otherwise, convert to FLOAT array. This is consistent with treatment of FLOAT in Rhai, which is: a + b is only INT if and only if a and b are both INT.

let (ints, floats) = arr.iter().fold((0, 0), |(i, f), x| {
    if x.is::<INT>() {
        (i + 1, f)
    } else if x.is::<FLOAT>() {
        (i, f + 1)
    } else {
        (i, f)
    }
});

if ints + floats < arr.len() {
    // raise error as some elements are not numeric
} else if floats == 0 {
    let i_vec = arr.iter().map(|x| x.as_int().unwrap()).collect::<Vec<_>>();
} else {
    let f_vec = arr
        .iter()
        .map(|x| {
            if x.is::<FLOAT>() {
                x.as_float().unwrap()
            } else {
                x.as_int().unwrap() as FLOAT
            }
        })
        .collect::<Vec<_>>();
}

Added types and size checks, primarily for functions that accept Array or Dynamic inputs. Also removed a substantial amount of duplication.

Closes #5.

For some reason, using resolver = "2" doesn't work, probably due to the sub-dependency on rhai_codegen. Which is a pity.

However, it is standard to have a metadata feature on packages to turn on/off docs.

In constants.rs and cumulative.rs, I see the primary numeric types used are i64 and f64. There are also a couple of checks in matrices_and_arrays.rs that checks for ::is<i64>(). I'm wondering if that's intentional. It should be better to use INT and FLOAT as much as possible, so that the user can use this library on 32-bit systems.

There is a pprint function in the example script, I wonder if that's a typo...

Originally posted by @schungx in https://github.com/rhaiscript/rhai-sci/pull/11#issuecomment-1207418837