Yes it will raise an error, as in Octave. The code will also check overflows.

Double is indeed the norm in Scilab. You can have an exemple of this with the factorial() function in Scilab. This integer in essence function does not even accept integers as input !

-->factorial(3.0)
ans =
6.

-->factorial(3.2)
error 10000
....

-->factorial(int32(3))
error 10000
....

Simon

Le 06/02/2014 20:20, William S Fulton a écrit :
What do you plan to happen when you call

print smethod(22.2)

Presumably this will error out? If it silently loses precision, then I don't know that your approach is a good one and I can't see overloading working. If on the other hand you can reliably detect and extract a true integer out of a double in Scilab, then using doubles as the Scilab type everywhere seems reasonable. It sounds a bit inefficient and slower to me, but if this is the norm in Scilab, then fine.

William

On 05/02/14 10:10, Simon Marchetto wrote:
Once we agree on the principles, I will write a full and precise
specification, that should be included in the documentation.

Simon

Le 05/02/2014 10:57, Simon Marchetto a écrit :
Hello William,

In your mail of 10/03/2013, you proposed me to model the Scilab typemaps
on Octave:

"Python is usually a good reference, but it does separate out integral
and floating point values, so a cast from a number that is a floating
point number must be cast to an integral, eg:

short smethod(short d); // C code

# Python code
print smethod(int(22.0)) # Okay
print smethod(22.0) # Runtime error
print smethod(22) # Okay

Modelling on Octave ought to be a better fit where smethod(22.0) just
works.

Why do you want an option to add in casting like in Python? You could
just make life easier for users by modelling it instead on the Octave
module. Given the similarities between Octave, Matlab and Scilab, it
would be a good thing to have them working similarly."

That was a good idea to be consistent on what is done for other
languages that are close to Scilab, as Octave is.

In Scilab as in Octave, the double type is the mostly used type, you
barely use integers.
So Swig Scilab should convert in intput/output integer from/to double,
if possible.

We have this behavior in Octave. I have just tested it now: SWIG Octave
converts from double to integer in input, and from integer to double in
output.

At first, I thought as a developer, and so was a bit scared to impose
theses automatic conversions. But I find no use cases where an integer
should be returned as this to Scilab, as Scilab can deal with doubles
everywhere, but can have some troubles with integers.

Simon

Le 02/02/2014 20:58, William S Fulton a écrit :
Simon

This isn't clear to me what you will be doing. I think you need to
write a more precise specification. It seems to me that for a given C
numeric type as input, the marshalling should try its hardest to
convert the Scilab type (be it a boolean, signed or unsigned integer
type or double) into the given C numeric type. If it can't then it
should give some sort of overflow error. With regard to output types,
then if the C type is a signed integer type it should be converted
into a signed Scilab integer. I don't see why you want to convert a C
int in output to a Scilab double, you should use the closest match in
size and sign to the C integer type. I suggest you next make a
complete table of C types and Scilab types that you will convert to
and from. This should form part of the documentation too.

William

On 30/01/14 09:47, Simon Marchetto wrote:
OK, I agree.

So are we going on the following behavior ?
- Scilab double or integer in input => C int
- C int in output => Scilab double
- C unsigned int <=> Scilab unsigned integer

(same for short, and long).

It is the behavior you proposed last time, and which is currently used
in Octave, if I remembered what you told me ?

Maybe there are some use cases in which we want absolutely a Scilab
signed integer returned, but in fact I can't see anyone for now.
We'll see on using.

About bool: there is a Scilab boolean type, mapping should be
direct, no
other conversion.

Simon

Le 29/01/2014 23:40, William S Fulton a écrit :
Simon,

Your plan sounds reasonable. Definitely any fine tuning such as memory
leak fixes can be done in later releases. Indeed the basic typemaps
for primitives should work correctly. Also basic STL like std::vector
should work reasonably well, at the minimum generating compilable code
even if they cannot be usefully used from Scilab. In summary the
test-suite should pass if these basics are all ready. SWIG is very
forgiving and can easily generate compilable code even if all types
are practically unusable and this is the minimum accepted standard.
From what I recall of the Scilab test-suite you were practically
there
until something went wrong in the primitive typemaps and vectors.

What precisely do you mean by the Scilab integers will only be used if
the wrapped function specified signed or unsigned integers. All
integers in C are either signed or unsigned, they can't be anything
else! If you are thinking that 'signed' or 'signed int' should behave
differently to 'int', then I will contest that. Surely you mean all
integer types will convert to an equivalent Scilab integer type
without exception and the only 'other cases' are floating point types,
which of couse should map to a Scilab double? What about bool?

William

On 29 January 2014 17:09, Simon Marchetto
<simon.marchetto@scilab-enterprises.com
<mailto:simon.marchetto@scilab-enterprises.com>> wrote:

Hello William,

I am back on SWIG ! I During the time I have been away, I could
some of them:

- We dont need a SWIG feature to set the behavior for primitive
typemaps (conversion to/from double or not). The Scilab (signed
and unsigned) integers will be used only if the wrapped function
signature specifies signed or unsigned integers. In other cases,
we convert from/to Scilab double, if possible. It is simpler. By
the way that was the initial behavior, but it still needs to be
fixed. The code of Scilab typemaps still need some cleaning in
general.

- Code generation : I wanted to optimize the generated code, to
reduce its size, and increase its performance. But it can wait
the
next version.

- Review of C/C++ features support. It will take too much time. I
will review the most important unit tests, fix them and add a few
if needed. I will do a complete review later.

- STL support : I will fix only the case of vector<class> (we'll
have to discuss about it) and a few other things (I need to
review
and probably clean the support of vector<enum>). I let away other
features of STL: iterators...

But I keep the task of finishing the documentation, which is one

Also a generated code is not usable if it has huge memory
leaks. I
do not think it will have any, but if I have time, I will do some
checks on memory management.

I hope I can finish all this soon.

Regards,

Simon

Le 20/12/2013 21:26, William S Fulton a écrit :

I don't think you need go overboard on the tests for
acceptance into master. So long as the test-suite passes and
you have a few runtime tests (you already have enough), then
I'll merge it into master. You can add improvements over
time.
All I think you need to do is get the primitive typemaps
working as these are fundamental.

With regard to checklists for C/C++ features supported, if
the
test-suite compiles and your tests include things like enums,
global functions and variables, static and non-static class
methods and variables, you'll find that you'll have a lot
covered as a lot of the detail is handled in the core. Adding
in stl wrappers etc can come later.

William

On 20/12/13 08:30, Simon Marchetto wrote:

Hello,

Yes unfortunately I was away from SWIG. My aim is also to
the major version SWIG 3.
I am not sure if it is still possible now, if we want to
keep high quality.

- finish the C++ support: fix the vector<class> case,
maybe a few small
other things
- fix primitive type typemaps, mostly about integer and
double. I would
like to introduce a SWIG feature that sets the
behavior of
that
typemaps: either convert automatically int from/to Scilab
double as
Octave does, or keep integers as integers.
- finish the documentation
- check memory management
- some refactoring : the generated code maybe or more
organized or
smaller (optional)
- also, and what is the most important to me :  I do not
have a clear
and complete view on what is supported or not by SWIG
Scilab. I would
like to build a check list of support status for all C or
C++ features.
For this, I need to analyze also all the unit tests, and
maybe I need to

Each of these task may be not so long to complete, but
the
sum could
take a couple of weeks.

Simon

Le 18/12/2013 01:21, William S Fulton a écrit :

What is the latest status for Scilab? Perhaps I've
got
it wrong, but
not much development has happened recently and we are
now in the final
stages for putting out SWIG 3 and really I'd like
for this release.

William

------------------------------------------------------------------------------

Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.