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 !

ans =

error 10000

error 10000


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.


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.


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

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

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.


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

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.


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.


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

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
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?


On 29 January 2014 17:09, Simon Marchetto
<>> wrote:

     Hello William,

     I am back on SWIG ! I During the time I have been away, I could
     think about the initial tasks planned below. I decided to revise
     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

     - Code generation : I wanted to optimize the generated code, to
     reduce its size, and increase its performance. But it can wait
     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
     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
     of the most important tasks.

     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.



     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
         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
         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.


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


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

             My planned tasks were:
             - 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
             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
             add some tests too.

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


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

                 What is the latest status for Scilab? Perhaps I've
                 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
                 Scilab support added
                 for this release.



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

Swig-devel mailing list